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VOORWOORD 


Dit boek is gericht op de behandeling van de grondslagen voor de 
logische structuur van databases. Het bestaat uit drie delen. Het 
eerste deel is bedoeld als een eerste kennismaking met databases en 
hun omgeving. Daarin wordt nagegaan hoe het fenomeen database 
en het daaromheen hangende jargon is ontstaan en welke problemen 
om een (formele) oplossing vragen. 

Het tweede deel is het meest omvangrijke. Het Sch de naam 
verzamelingsmodel meegekregen. Velen zijn het erover eens, dat de 
verzamelingsleer van groot nut kan zijn bij de oplossing van data- 
baseproblemen. Om dit echter gestalte te geven in een adequaat for- 
meel model, is blijkbaar toch niet zo eenvoudig. De afgelopen jaren 
heb ik namelijk bij cursussen in het hoger onderwijs en daarbuiten 
moeten ervaren, dat het een illusie is te veronderstellen dat 
'modern' opgeleide personen een behoorlijke kennis van verzamelings- 
leer hebben, laat staan zulke kennis kunnen gebruiken. Men moet 
dan ook niet verwachten, dat toepassing van verzamelingsleer bij 
het oplossen van databaseproblemen een eenvoudige zaak is. Het is 
echter wel mogelijk, maar dan dient het te geschieden via een streng 
formele en systematische opzet. De ervaringen van de afgelopen 
jaren hebben geleerd, dat menig student in het begin flink moet 
worstelen met de materie van het tweede deel, maar achteraf dan wel 
kan vaststellen, dat hij daarmee een solide en werkzaam begrippen- 
kader ter beschikking heeft gekregen. Vrijwel alle definities in dit 
tweede deel worden gegeven in twee vormen: niet formeel en formeel. 
De niet-formele vorm is bedoeld als een 'steuntje in de rug' voor het 
begrijpen van de formele vorm. Dat dit steuntje geen overbodige 
luxe is (gebleken) hangt samen met het boven gesignaleerde gebrek 
aan kennis van verzamelingsleer. 

In het derde deel wordt nagegaan hoe de logische structuur van 
het verzamelingsmodel kan worden weergegeven in een belangrijke 
klasse van database-managementsystemen, namelijk die welke geba- 
seerd zijn op het zogeheten netwerkmodel. Evaluatie van dit model 
vindt plaats met behulp van de theorie uit het tweede deel. 


Gezien de doelstelling van dit boek, grondslagen voor de logische 
structuur, mag beslist niet verwacht worden dat in dit boek ‘alles te 
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vinden is' over databases. De lezer zij gewaarschuwd. Er is veel dat 
niet of maar in zeer beperkte mate in dit boek staat: vrijwel niets 
over de fysieke organisatie van de gegevens, niets over het hiċrar- 
chisch model, niets over methoden, heel weinig over beschikbare 
vraagtalen, niets over privacy-problemen. Ik zou zo nog wel even 
kunnen doorgaan. Men versta mij wel. Genoemde onderwerpen zijn 
beslist niet onbelangrijk. De reden echter, dat zij in dit boek niet 
of nauwelijks worden behandeld is, dat een enigszins volledige uit- 
werking van bovengenoemde doelstelling een goed afgerond geheel 
vormt, waar men blijkens de ervaringen van de afgelopen jaren 
‘reeds de handen vol aan heeft'. Ik hoop dan ook, dat de lezer in dit 
boek ook zaken zal aantreffen, die elders niet of zeker niet in die 
mate te vinden zijn. Dit geldt dan met name voor het tweede deel en 
voor de wijze waarop behandeling en evaluatie van het netwerkmodel 
plaatsvindt. 


De meeste hoofdstukken zijn voorzien van een groot aantal opgaven. 
Voor het verwerven van een goed begrip van de geboden stof kun- 
nen deze opgaven een uiterst nuttige functie vervullen. 


In hoofdstuk 7 wordt een (naar gangbare onderwijsbegrippen) 
omvangrijke database gedefinieerd. Deze biedt door het relatief gro- 
te aantal objecten en hun onderlinge verbanden veel mogelijkheden 
om de echte databaseproblemen, namelijk die van massa en complexi- 
teit, aan bod te laten komen. 


Voor de samenstelling van dit boek ben ik veel dank verschuldigd 
aan collega's en studenten. Hun talloze vragen en opmerkingen heb- 
ben tot vele aanvullingen en verbeteringen geleid. 

Een apart woord van dank is op zijn plaats aan Frans Groen van 
de BIO-Arnhem. En tenslotte wil ik een heel bijzonder woord van 
dank richten aan Bert de Brock van de TH-Eindhoven, voor met 
name de uitgebreide en deskundige medewerking aan de totstandko- 
ming van het tweede deel. 


Voor op- en aanmerkingen houd ik mij uiteraard gaarne aanbevolen. 


Eindhoven, juli 1982. F. Remmen 
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DEEL | 
KENNISMAKING MET DATABASES EN HUN OMGEVING 


1 DATABASES EN HUN OMGEVING 


1.1 HISTORISCHE ONTWIKKELING VAN GEGEVENSSTRUCTUREN 


Om een organisatie (overheidsinstelling of particulier bedrijf) goed 
te kunnen besturen, moeten op bepaalde momenten de nodige beslis- 
singen worden genomen. Voor het nemen van deze beslissingen is 
informatie nodig (BEM, hfdst.1). 

Deze informatie zal in het algemeen niet kant en klaar beschikbaar 
zijn. Er zal dan ook een speciaal produktiesysteem moeten zijn, dat 
zorgt dat de gewenste informatie wel beschikbaar komt. Zo'n speciaal 
produktiesysteem noemen wij een informatiesysteem. 

Zoals in elk produktiesysteem kunnen wij ook in een informatie- 
systeem spreken van 
— het gewenste produkt, in casu de gewenste informatie; hiervoor 

wordt ook dikwijls de benaming informatiebehoefte gebruikt; 

— de grondstoffen, die nodig zijn voor het maken van het gewenste 
produkt, in casu de gegevens (data); 

— het proces, waarmee de grondstoffen worden verwerkt tot het 
gewenste eindprodukt, in casu het programma. 


Deze drie elementen vindt men ook terug in het onderstaande schema 
(LUNREM, hfdst.1). 


eindprodukt 
(informatie; 
output) 


(bewerking; 
programma) 


input) 


Alleen als de gegevens goed geordend zijn, kan er sprake zijn van 
een betrouwbaar en efficiënt informatiesysteem. Aan zo'n ordening 
van gegevens zal een goede gegevensstructuur ten grondslag moe- 
ten liggen. | 

Deze gegevensstructuur moet uiteraard ontleend zijn aan de doel- 
stelling van het informatiesysteem. Met andere woorden: uit de 
informatiebehoefte moet worden afgeleid, welke structuur voor de 
gegevens geschikt is en met welk verwerkingsproces dan uiteindelijk 


aan de informatiebehoefte zal worden voldaan. 


Het probleem van gegevensstructurering was in de vijftiger en begin 
zestiger jaren nog (betrekkelijk) eenvoudig. Gezien de toenmalige 
(beperkte) technologische mogelijkheden, die alleen sequentieel toe- 
gankelijke achtergrondgeheugens toelieten, kon men voor informatie- 
systemen alleen maar denken aan eenvoudige gegevensverzamelingen. 

Elk van deze gegevensverzamelingen bestond uit gegevenseenhe- 
den, die op dezelfde soort van zaken betrekking hadden, of, meer 
technisch uitgedrukt: elke gegevensverzameling bestond uit één 
bestand van records. Voorbeelden: werknemersbestand, artikelen- 
bestand, klantenbestand. 

Met de komst van direct toegankelijke achtergrondgeheugens ging 
het beeld zich wijzigen. Zoals bij zoveel ontwikkelingen, gold ook 
hier: meer mogelijkheden, meer (informatie)behoeften. Of liever: 
deze (verdergaande) behoeften waren voorheen wel latent aanwezig, 
maar werden niet expliciet naar voren gebracht vanwege de (terech- 
te) verwachting, dat er toch niet aan voldaan zou kunnen worden. 

De informatiebehoeften, die met de voortgaande technologische 
ontwikkeling aan de oppervlakte kwamen, hadden met name betrek- 
king op: 

- verbanden tussen verschillende soorten gegevens, bijvoorbeeld 
tussen | 

—- klant- en ordergegevens in een handelsonderneming 

-- afdeling- en patiëntgegevens in een ziekenhuis 

—- docent-, student- en vakgegevens in een onderwijsorganisatie; 
- het ('gelijktijdig') gebruik door verschillende gebruikers (groepen) 

van (gedeelten van) de totale gegevensverzameling. Zo zijn bij- 

voorbeeld 

—- bedrijfsleiding en administratie geïnteresseerd in de artikel- 

gegevens 

—- specialisten en ziekenhuisadministratie geïnteresseerd in 

patiëntgegevens 

—- docenten en studentenadministratie geïnteresseerd in studen- 

tengegevens. 


Niet elke (groep van) gebruiker(s) hoeft uiteraard in dezelfde gege- 
vens geïnteresseerd te zijn. Hierop komen wij nog uitgebreid terug 
(in de toelichting op het begrip horizontale onafhankelijkheid). 


Met direct toegankelijke achtergrondgeheugens werd het mogelijk 
bovengenoemde verbanden tussen gegevenssoorten zodanig op te 
slaan, dat de gegevens ook redelijk toegankelijk werden volgens 
deze verbanden. 

VOORBEELD. Met een niet-direct toegankelijk achtergrondgeheu- 
gen is het een vrijwel onbegonnen taak om bij een willekeurig klan- 
tenrecord uit het klantenbestand snel de bijbehorende orders uit het 
orderbestand ter beschikking te krijgen. Met een direct toegankelijk 


4 


achtergrondgeheugen is dit wel te verwezenlijken door bijvoorbeeld 
van het desbetreffende klantenrecord een ketting van bijbehorende 
orderrecords aan te leggen. 


Naast het weergeven van genoemde verbanden in de gegevensstruc- 
turen, werden er ook pogingen ondernomen om in te spelen op de 
behoefte om alle gegevens van alle soorten tezamen weer te geven in 
één grote (gemeenschappelijke) gegevensverzameling. En dan duikt, 
eigenlijk ineens, de term database op. In juni 1963 is er in Santa 
Monica (VS) namelijk een symposium met de titel 'Development and 
management of a computer-centered Data Base! gehouden. Voor ver- 
dere historische informatie zij verwezen naar Olle (OLLE, hfdst.1). 

In de loop van de zestiger jaren worden diverse (software manage- 
ment) systemen ontwikkeld, die een min of meer geïntegreerd 
gebruik van bestanden mogelijk maken, zonder dat de gebruiker/ 
programmeur daarvoor uitgebreide eigen voorzieningen moet treffen. 
Voorbeelden zijn de systemen NIP S/FFS van IBM, IDS van General 
Electric, ADAM van de MITRE Corp., IDMS van System Development 
Corp., DISK FORTE van Burroughs. Voor meer en uitgebreide infor- 
matie hierover zij verwezen naar het desbetreffende rapport van het 
CODASYL Systems Committee (CODASYL 69). 

In het algemeen kan men zeggen, dat elk van deze systemen ont- 
stond als uitbreiding van bestaande (data management) systemen. 
Zulke uitbreidingen hebben echter meestal het nadeel, dat de over- 
zichtelijkheid afneemt. Naar analogie van opgevoerde motoren zou 
men hier kunnen spreken van opgevoerde data management systemen. 
En zoals meer bij opgevoerde systemen blijkt, heeft men dan te 
maken met een instrument, dat eigenlijk niet helemaal geschikt is 
voor het verwezenlijkne van de (nieuwe) doelstelling. Men ging zich 
dan ook afvragen of de zaak niet grondiger moest worden aangepakt, 
namelijk eerst kijken naar het (gegevens)probleem en dan aangepast 
gereedschap ontwikkelen. 

Met andere woorden: men diende meer de architectuur van een 
database als uitgangspunt te nemen. Dit gebeurde onder meer door 
de Data Base Task Group (afkorting: DBTG) van het CODASYL 
Programming Language Committee. Het is overigens interessant om 
op te merken en tekenend voor de historische context, dat de (oor- 
spronkelijke) taak van de DBTG (was) is: "to define extensions to 
COBOL to handle databases". 

Olle geeft een interessante schets over het ontstaan en de evolu- 
tie van de DBTG en andere groepen binnen CODASYL-verband 
(OLLE, $ 1.3-1.5). 

In 1971 bracht de DBTG een inmiddels welbekend rapport uit 
(CODASYL 71). Hierop zullen wij uitgebreid ingaan in het derde 
deel van dit boek. Dit rapport is bedoeld als een machine-onafhan- 
kelijk voorstel van taalelementen, nodig voor de beschrijving en 
het gebruik van een database. 

Deze machine-onafhankelijke opstelling heeft echter niet verhin- 


derd, dat in het DBTG-rapport taalelementen worden voorgesteld, die 
betrekking hebben zowel op het hoogste logische niveau van de 
gebruiker als op lager liggende niveaus van implementatie. Dit komt 
de doorzichtigheid uiteraard niet ten goede. Met name bij uitgebreide 
toepassingen wordt het daardoor moeilijk de diverse fasen in de 

opzet van een database duidelijk te onderscheiden. 

Eind zestiger jaren/begin zeventiger jaren ontstond, vooral onder 
aanvoering van E.F. Codd, een streven om een model te ontwerpen, 
waarin de architectuur van een database op het logische niveau dui- 
delijk naar voren komt (CODD 70). Hierbij wordt gebruik gemaakt 
van het wiskundige begrip relatie. Daarvandaan de naam relationele 
model. Eigenlijk is dit het begin geweest van een meer fundamentele, 
systematisch gerichte aanpak van ontwerp en gebruik van databases. 
Hetgeen overigens niet wil zeggen dat de (lawine van) literatuur 
over het relationele model de kwalificatie fundamenteel en systema- 
tisch verdient. 

Met name de wiskundige ondergrond is op vele literatuurplaatsen 
erg zwak, met het gevolg dat het begrip van gegevensstructurering 
wazig wordt en het gebruik van gegevens ondoorzichtig niettegen- 
staande de zogeheten user-friendly query-languages. 

Aan de fundamentele opbouw zal in dit boek veel aandacht worden 
geschonken. Het zal zelfs het belangrijkste en grootste deel van dit 
boek vormen. Omdat deze opbouw plaatsvindt met behulp van de 
verzamelingenleer, heb ik dit deel 'verzamelingsmodel' genoemd. 


Om enig idee te hebben van de omgevingswereld van databases en het 
daarin gebruikte 'jargon', komen in dit inleidende hoofdstuk nog de 
volgende onderwerpen aan bod: 

- omschrijving van het begrip database 

— de organisatie rondom een database 

— data independence en conceptual schema 

— database modellen. 


1.2 OMSCHRIJVING VAN HET BEGRIP DATABASE 


In het volgende deel zullen wij tot een formele definitie van een zoge- 
heten databasetvpe komen. In deze paragraaf zullen wij met behulp 
van een minder formele definitie trachten aan te geven, welke aspec- 
ten van belang zijn bij een database. We zullen in deze paragraaf 
verder kortheidshalve het woord definitie gebruiken, maar dan in de 
betekenis van niet-formele omschrijving. 

Het aantal database-definities, dat in omloop is, is welhaast net 
zo groot als het aantal schrijvers over dit onderwerp, en dat is 
waarlijk niet gering. Met een variant op een bekend gezegde zou men 
in dit verband kunnen spreken van 'quot capita, tot definitiones' 
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(‘zoveel hoofden, zoveel definities'). Ik zal er hier enkele aanhalen 
(uit boeken, verschenen sinds 1975). 


Knuth: "A large file or a group of files is frequently called a 
database." 
Olle: TA database (is) a crossreferenced collection of data 


records of different types." (OLLE, 8). In tegenstelling tot 
de database wordt door Olle de file gedefinieerd als "a collec- 
tion of records, which is not crossreferenced and in which 
the records are normally all of the same type" (OLLE, 8). 


Palmer: TA widely accepted definition of a database is: 
-TAn organized, integrated collection of data; 
— a natural representation of the data, with no imposed 
restrictions or modifications to suit a computer; 
— capable of use by alle relevant applications, without 
duplication of data"". 


Date: TA working definition of database (based on one given bv 
Engles): A database is a collection of stored operational 
data used bv the application svstems of some particular 
enterprise." (DATE, 7). 


Martin: TA database may be defined as a collection of interrelated 
4 data stored together without harmful or unnecessary 
redundancy to serve multiple applications." (MARTIN, 
22). 


Zonder deze definities in detail te bespreken (is ook weinig zinvol) 
kan volgens mij wel gesteld worden, dat Knuth erg onvolledig is, 
Palmer te wijdlopig en vaag en dat de definities van Olle, Date en 
Martin tezamen wel ongeveer weergeven wat de essentiële kenmerken 
van een database dienen te zijn. 


Onderstaande definitie is bedoeld als een poging mijnerzijds om het 
begrip database duidelijk en volledig weer te geven. 


Een database is een verzameling van permanente gegevens, die 
ter beschikking staat van alle gebruikers van een informatie- 
systeem. Deze gegevens hebben betrekking op de voor het infor- 
matiesysteem relevante objecten en de bij deze objecten behorende 
relevante kenmerken. 


Er volgt nu een nadere toelichting op (verschillende onderdelen van) 
deze definitie. 


- Verzameling van permanente gegevens. 
Wij spreken van permanente gegevens, als deze ook buiten de 
programma's, die gebruik maken van deze gegevens en eventueel 


zelfs de waarde daarvan wijzigen, moeten blijven béstaan (voor 
een bepaalde periode). 

Niet-permanente (tijdelijke) gegevens zijn eigenlijk altijd mutatie- 
gegevens. Dat tijdelijke gegevens dikwijls nog enige tijd bewaard 
blijven, is eigenlijk in principe overbodig, maar wel nodig, zelfs 
noodzakelijk, in verband met herstel van mogelijk optredende 
storingen en fouten. 

Voorbeeld. Tot de permanente gegevens in een onderwijsorganisa- 
tie behoren onder meer naam, adres, woonplaats van elke student. 
Een adresmutatie is een tijdelijk gegeven. 


Deze permanente gegevens dienen ter beschikking te staan van 
alle gebruikers van een informatiesysteem. 
Deze bestemming voor vele gebruikers heeft belangrijke conse- 
quenties. Immers verschillende groepen gebruikers zullen op ver- 
schillende manieren geïnteresseerd zijn in de gegevens. Zo zal 
een administrateur in een ziekenhuisorganisatie behoefte hebben 
aan financiële gegevens over personen en tarieven, terwijl een 
specialist moet kunnen beschikken over (medische) gegevens van 
personen en van toe te passen behandelingen. 
Date (DATE, 7) spreekt van "the application systems of some 
particular enterprise". Per enterprise (een apart informatiesys- 
teem en) dus een aparte database. Dit kan een onnodige beper- 
king zijn. Informatiesystemen, en bijbehorende databases, die 
betrekking hebben op combinaties van 'gelijksoortige enterprises! 
bestaan reeds, zoals voor combinaties van ziekenhuizen. Systemen 
voor combinaties van ‘ongelijksoortige! organisaties zijn in prin- 
cipe ook mogelijk, maar in de praktijk komen ze (bij mijn weten) 
(nog) niet voor. Misschien is dit in de toekomst wel te verwach- 
ten bij gebruik op grotere schaal van gedistribueerde gegevens- 
verwerking. 
Er kan zelfs sprake zijn van (deels) tegenstrijdige belangen voor 
verschillende groepen. Met name kan dit optreden in verband met 
de gewenste gegevensopslag. Als bijvoorbeeld ordergegevens 
'dichtbij' klantgegevens liggen opgeslagen ten gerieve van de fac- 
tuurafdeling, dan is dat minder prettig voor de produktieafde- 
ling, die de ordergegevens liever 'dichtbij' de fabricagegegevens 
heeft. 
Het ontwerp en de implementatie van een database zal daarom een 
compromis zijn tussen de verschillende (deels tegenstrijdige) ver- 
langens van de verschillende gebruikers(groepen). 
Voor dit compromis is een neutrale instantie! nodig, in de vorm 
van een zogeheten DBA (Data Base Administrator). De DBA heeft 
aus tot taak 

een redelijk compromis tot stand te brengen tussen de (tegen- 

strijdige) gebruikersbelangen. Hieruit volgt dat tot zijn ver- 

antwoordelijkheid o.a. hoort | 

— het definiëren en laden van de database 


— de toegangs- en onderhoudsstrategie van de database (wie 
mag wat gebruiken, wie mag wat veranderen) 
De taak van een DBA is verre van eenvoudig. Data zegt dan ook 
terecht dat "the position of a DBA is a very senior one!" (DATE, 
10). Voor een uitgebreide taakbeschrijving van een DBA zij ver- 
wezen naar Date (DATE, 25-27). 


In onderstaande tekening (van Mandy Kaas uit Eindhoven) is op 
ludieke wijze weergegeven hoe vele verschillende (groepen van) 
gebruikers verschillend tegen een database aankijken. 


De gegevens hebben betrekking op de voor het informatiesysteem 

relevante objecten en de bij deze objecten behorende relevante 

kenmerken. 

Hiermee raken wij aan een heel belangrijk onderwerp in de data- 

base wereld. Het heeft al heel wat verhitte discussies opgeroepen 

met meer scheiding dan vereniging der geesten als resultaat. 

Het ontwerpen van een adequaat formeel systeem voor het vast- 

leggen van en manipuleren met relevante objecten en kenmerken, 

is een uiterst moeilijke en eigenlijk nog maar net op gang gekomen 

zaak. Het is dan ook te betreuren, als deze toch al niet eenvoudi- 

ge zaak onnodig bemoeilijkt wordt door: 

a. het niet goed uit elkaar houden van de begrippen 'soort' en 
'individu'; 

b. de heilloze verwarring die ontstaat, door te stellen dat de 


begrippen 'object' en ‘kenmerk! uitwisselbaar zijn. 
Elk van deze twee punten wordt nu nader besproken. 


Ad a 

Het verschil tussen soort en individu wordt in gangbare database 
terminologie meestal aangegeven met het verschil tussen type en 
occurrence. Men kan bijvoorbeeld spreken van het (object)type 
student, en van de (object)occurrences van alle studenten van een 
onderwijsinstelling. Het gaat in dit voorbeeld dan om één type 
(soort) met vele occurrences (individuen). 

Codd heeft terecht opgemerkt, dat het niet goed onderscheiden 
van type en occurrence een bron kan zijn van vele onduidelijkheden 
en fouten. 

Wij willen in dit verband nog wijzen op een belangrijke zaak, 
namelijk de wijze waarop (ten behoeve van onderlinge communicatie) 
een type en de occurrences van een type worden gerepresenteerd. 
Wij kunnen de benaming 'student' gebruiken voor het representeren 
van een objecttype. 

Voor het representeren van één occurrence van dit type, dus van 
een individuele student, zullen wij waarden nodig hebben van één of 
meer kenmerken van deze individuele student, bijvoorbeeld JANSEN 
(waarde van kenmerk achternaam), ZEEPAD 15 (waarde van kenmerk 
woonplaats), EINDHOVEN (waarde van kenmerk woonplaats). Een 
andere representatie zou zijn met behulp van het kenmerk registra- 
tienummer, dat in dit geval bijvoorbeeld de waarde 101973 zou kun- 
nen hebben. 


Ad b 

Volgens o.a. Smith & Smith kan een object eventueel ook als kenmerk 
optreden. Deze bewering wordt dan 'geschraagd' met het begrip 
'Objectrelativiteit' (SMITH, 42). Dit begrip klinkt aardig, maar maakt 
een duidelijke behandeling van gegevensstructuren erg moeilijk, zo 
niet onmogelijk. 

Men is m.i. tot dit (wan)begrip gekomen, doordat men in de 
natuurlijke taal toegestane maar onnauwkeurige benamingen zonder 
meer heeft overgenomen in de formele beschrijving van gegevens- 
structuren. Een voorbeeld moge een en ander verduidelijken. 

Stel gegeven is het object 'auto' met de kenmerken: kenteken, 
bouwjaar, kleur, eigenaar. Het is zeer wel denkbaar, dat in het 
informatiesysteem naast 'auto' ook 'eigenaar' een relevant object 
is, met bijvoorbeeld de kenmerken: naam, adres, woonplaats , 
telefoonnummer. Ogenschijnlijk treedt nu eigenaar op als kenmerk, 
maar ook als object. In feite wordt echter met het kenmerk ‘eigenaar’ 
bij het object 'auto' een kenmerk bedoeld, zoals 'naam van eigenaar’. 
Dit zal met name duidelijk worden als men een waarde van het ken- 
merk 'eigenaar' wil weergeven. 

Naar aanleiding van het juist gegeven voorbeeld zij nogmaals 
gewezen op het reeds ad a genoemde onderscheid tussen type en 
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en occurrence. 'Auto is namelijk wel een naam van het onderhavige 
type, maar kan niet de naam zijn van een occurrence van dit type. 


Na het bovenstaande moge het volgende uitgangspunt duidelijk zijn: 


Een object kan nooit optreden als kenmerk en een kenmerk nooit als 
object. 


Tenslotte moet nadrukkelijk worden opgemerkt, dat de relevantie 
van een object of een kenmerk voor een informatiesysteem uitsluitend 
kan worden bepaald door de gebruiker(s) en niet door degenen, die 
verantwoordelijk zijn voor de bouw van de database. 


1.3 DE ORGANISATIE RONDOM EEN DATABASE 


Om de objecttvpen en kenmerktypen van een database te kunnen 
beschrijven, moet men kunnen beschikken over een zogeheten DDL 
(Data Description Language). (Vergelijk de taalelementen voor het 
declaratiegedeelte in ALGOL en PASCAL en voor de DATA DIVISION 
in COBOL.) 

Een beschrijving van een database, zoals hierboven bedoeld, 
wordt ook wel een schema genoemd. Voor één bepaalde toepassing 
zal het als regel niet nodig zijn dat men de (beschrijving van de) 
gehele database, dus het totale schema, ter beschikking heeft. 
Daarom kan men dikwijls volstaan met deelbeschrijvingen, zogeheten 
subschema's. 

Voor het onderhoud van de database (invoegen, veranderen, ver- 
wijderen van gegevens) en voor het gebruik van de gegevens in de 
database, moet men dan verder kunnen beschikken over een zogehe- 
ten DML (Data Manipulation Language). Een DML kan deel uitmaken, 
of poros gezegd een uitbreiding zijn van een reeds bestaande 'gewo- 
ne' programmeertaal, zoals COBOL of FORTRAN. Men noemt die 
reeds bestaande taal dan een host language. Is een DML geen onder- 
deel van een host language, dan spreekt men van een self contained 
DML. 

Voor een DDL kunnen analoge opmerkingen worden gemaakt. 

Een waarschuwing voor mogelijke begripsverwarring is hier op 
zijn plaats. Zo wordt DML ook gebruikt als afkorting van Data 
Modelling Language, hetgeen hetzelfde is als de reeds eerder 
genoemde DDL. Voor Data Manipulation Language wordt ook 
gebruikt het (wat onduidelijke) begrip DSL (Data Sub Language) 
(DATE 6, 19). Om tenslotte de verwarring compleet te maken moet 
nog worden vermeld, dat DSL ook dikwijls wordt gebruikt als afkor- 
ting van Data Storage Language. Zo'n Data Storage Language is 
nodig om de opslagstructuur van de gegevens te beschrijven. 
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In het algemeen zal een DML vrij eenvoudig van opzet zijn (een 
gering aantal relatief eenvoudige taalelementen). Dit betekent niet 
dat onderhoud en gebruik van een database een eenvoudige zaak is. 

Het is echter niet de bedoeling de gebruikers via een ingewikkel- 
de DML op te schepen met het gecompliceerde probleem van database 
benadering. Daarvoor is een uitgebreid pakket van speciale pro- 
grammatuur beschikbaar, het zogeheten DBMS (Data Base Manage- 
ment System). "The DBMS is the software that handles all access to 
the database." (DATE, 25). Zo'n DBMS is een programmapakket met 
een niet ongebruikelijke orde van grootte van 50K woorden. 


Elke gebruiker communiceert via het DBMS met de database (zie 
figuur 1.1). 


Figuur 1.1 Plaats van een DBMS. 


Een DBMS kan in feite worden beschouwd als een speciale uitbreiding 
van het operating system. Om de rol ervan nog iets duidelijker 
(ofschoon nog zeer schematisch) aan te geven, moge figuur 1.2 die- 
nen, waarin in grote lijnen wordt aangegeven hoe een aanvraag van- 
uit een programma naar een bepaald gegeven uit de database via het 
DBMS tot stand komt. 


Werkgeheugen 


Operating System 


Ophaal-programma 
Lief Lee Le N 
Programma- 1 NC a-1 


Achtergrondgeheugen 


Database 


Figuur 1.2 Verwerking van een ophaalopdracht m.b.v. een DBMS. 
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Hierbij is het volgende op te merken: 


pijl 1 Ophaalopdracht in programma 1 wordt doorgegeven aan 
DBMS 

pijlen 2 Met behulp van subschema en schema wordt de plaats van de 
gevraagde gegevens in de database bepaald 

pijlen 3 De gevraagde gegevens worden via de bufferruimte getrans- 
porteerd naar de (eigen) werkruimte van het aanvragende 
programma. 


Naast het relatief duidelijke begrip Data Base Management System 
komt men ook het begrip Data Base System (DBS) tegen. Volgens 
Date (DATE, 3) dient men daaronder te verstaan: de (fysieke) 
database zelf, dus de verzameling van de gegevens plus batch toe- 
passingsprogramma's en terminal gebruikers. Wij zullen het begrip 
in een meer omvattende zin gebruiken, namelijk de (fysieke) database 
zelf en de hele organisatie (aan apparatuur en programmatuur en 
mensen), die nodig is voor onderhoud en gebruik van de database. 


1.4 DATA INDEPENDENCE EN CONCEPTUAL SCHEMA 


Bij het (structureren) vastleggen van gegevens kunnen wij spreken 
van verschillende elkaar opvolgende fasen. Hoeveel fasen men in fei- 
te wil onderscheiden, is op zich niet zo belangrijk. Immers, het 
onderscheid in fasen geschiedt om op deze wijze het vastleggen van 
gegevens op een overzichtelijke wijze tot stand te kunnen brengen. 
Ingewikkelde zaken kunnen nu eenmal het beste stuksgewijs worden 
uit gevoerd. 
Bij het vastleggen van gegevens zouden wij bijvoorbeeld de vol- 
gende fasen kunnen onderscheiden: 
— de logische fase, waarin de zogeheten logische structuur wordt 
vastgelegd. 
Wat deze logische structuur precies inhoudt zal voor een groot 
gedeelte het onderwerp van de volgende hoofdstukken zijn. 
Intuïtief kunnen wij ons nu echter daarvan al wel enigszins een 
beeld vormen. Bij de logische fase denken wij namelijk aan het 
vastleggen van de (relevante) objecttvpen en hun kenmerken, 
zonder daarbij ook maar enige aandacht te besteden aan opslag- 
en toegangsproblemen. 
— de opslagfase, waarin de zogeheten opslagstructuur (Storage 
Structure) wordt vastgelegd. ġġ 
Men denke hier bijvoorbeeld aan zaken als: keuze van bestands- 
organisatie voor de verschillende objecttvpen, vaststellen van 
(maximaal te verwachten) occurrences per objecttvpe, wijze waar- 
op directe toegankelijkheid (met bijvoorbeeld sleutelconversie) 
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gerealiseerd dient te worden. 
In deze fase komt de fysieke weergave van de gegevens nog niet 
aan de orde; dit gebeurt in 

— de fysieke fase, waarin de zogeheten fysieke structuur wordt 
vastgelegd. In deze fase wordt bijvoorbeeld bepaald welke opslag- 
media zullen worden gebruikt. 


Er werd reeds op gewezen dat deze indeling in fasen nog lang geen 
uitgekristalliseerde zaak is in de database-wereld. Hiervoor kunnen 
twee belangrijke oorzaken worden genoemd (die elkaar overigens 
beïnvloeden). 

Ten eerste is de theorie over databases nog veel te weinig (weten- 
schappelijk) ontwikkeld om al genoeg ondersteuning te geven voor 
een duidelijke markering in fasen. Ten tweede is er bij de tot nu toe 
operationeel beschikbare database management systemen niet of veel 
te weinig sprake van splitsing in (opeenvolgende) fasen. 

Zo komt het nogal eens voor, dat vanwege veranderingen in de 
database, die eigenlijk niet van belang zijn voor een gebruiker, deze 
toch genoodzaakt wordt (eventueel via de DBA) zijn gegevensdefini- 
ties en programma's te herzien met eventuele consequenties van 
opnieuw vertalen en laden. Als bijvoorbeeld een andere opslagvorm 
(dus een andere bestandsorganisatie) wordt gekozen voor een 
objecttype, dan moet een 'gewone' gebruiker daar eigenlijk 'geen 
last van hebben'. Deze afhankelijkheid van de gebruiker van voor 
hem eigenlijk irrelevante zaken, werkt irriterend en stagnerend. 

Het is dan ook voor de hand liggend dat er wordt gestreefd naar 
zogeheten data independence. Over dit begrip willen wij ons nu een 
zo duidelijk mogelijk beeld vormen, inclusief de prijs die ervoor 
betaald moet worden. 


Om een gebruiker te vrijwaren van bemoeienissen met ‘vreemde! 

zaken is het goed zich te realiseren, dat de gebruiker 

- alleen geïnteresseerd is in de logische (gegevens)structuur, dus 
niet in de implementatie van deze logische structuur; 

— op het logische niveau verder alleen geïnteresseerd is in voor 
hem relevante zaken. Zo zullen in een ziekenhuisorganisatie 
administrateur en specialist verschillende interessegebieden heb- 
ben. 


Vrijwaring van niet-relevante zaken op logisch niveau leidt tot zoge- 
heten horizontale data independence. Voor de gebruiker is het dan 
als omvat het logische niveau niet meer dan voor hem relevante zaken 
(de onderdelen XL-Vjpen x,-V in figuur 1.3). 

Vrijwaring van diverse impfementatiezaken leidt tot zogeheten 
verticale data independence. Voor de gebruiker is het dan alsof hij 
rechtstreeks kan opereren vanuit het hem bekende logische niveau, 
zonder dat daarvoor diverse implementatieniveaus nodig zijn. De 
niet-gearceerde vakjes van figuur 1.3 bestaan dus voor de gebruiker 
niet. 
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Figuur 1.3 Horizontale en verticale data independence. 


In feite omvat de database meer dan de gebruiker zich in zijn door 
horizontale en verticale data independence afgeschermde omgeving 
realiseert. Om deze onafhankelijkheid tot stand te brengen, zullen 
dan ook maatregelen moeten worden getroffen. 

Deze maatregelen hebben de vorm van een speciaal stuk software, 
zogeheten interfaces, die het verband leggen tussen de database 
wereld van de gebruiker en de totale database. Interfaces zijn de 
prijs, die betaald moet worden voor data independence. 

De mate van onafhankelijkheid is evenredig met de interface-soft- 
ware, die ervoor ingezet wordt. Deze prijs moet men niet gering 
achten (stijgende software-prijzen tegenover dalende hardware- 
prijzeni). 


In de literatuur (en in voorstellen voor standaardisatie) komt men 
nogal eens een afbeelding tegen, zoals in figuur 1.4. Deze afbeelding 
is dan bedoeld als een schets van de architectuur van een database 
svsteem. Merk nogmaals op, dat een database svsteem niet hetzelfde 
is als een database. Een database systeem omvat de database èn 

alles wat nodig is voor beschrijving en gebruik van de database. 


External External 


schema 1 schema n 


External 
schema n 


External 
schema 1 


schema 


Conceptual 


schema 


‚Interface 


Internal 
schema 


Internal 
schema 


Beschrijvingen ` 
Fysieke opslag 

op achter- 
grond- 


geheugen Stored Data Base 


Figuur 1.4 Architectuur van een database svsteem. 
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In feite wordt in figuur 1.4 hetzelfde weergegeven als in figuur 1.3, 
als men bedenkt dat 


het conceptual schema (figuur 1.4) de beschrijving is van de 
database op logisch niveau (A-Z in figuur 1.3); 
elk external schema (figuur 1.4) de beschrijving is van een 


gegevensgebied voor een bepaalde groep gebruikers Gig en 


X9-V9 in figuur 1.3); 


het internal schema (figuur 1.4) een afbeelding is van het con- 
ceptuele schema ten behoeve van efficiënte fysieke opslag. Dit 


is te vergelijken met het niveau A''-Z'' in figuur 1.3). 


In figuur 1.4 zouden, evenals in figuur 1.3, ook meerdere imple- 


mentatieniveaus kunnen worden weergegeven. 


16 


— de stored database (figuur 1.4) gelijk is aan de fysiek opgeslagen 
occurrences met bijbehorende ‘administratie! (de 'database' in 
figuur 1.3); 

— de onafhankelijkheid binnen en tussen de niveaus wordt waarge- 
maakt met behulp van interfaces (in figuur 1.3 niet getekend voor 
horizontale onafhankelijkheid). 


In dit boek zullen wij ons vooral bezighouden met het conceptuele 
schema, dus met de logische structuur. 

In dit verband zij er nogmaals nadrukkelijk op gewezen, dat voor 
het bepalen van de logische structuur alleen de betekenis van de 
gegevens van belang is. De logische structuur zal op haar beurt van 
invloed zijn op de opslagstructuur, maar het is daarvoor niet de enig 
bepalende factor. Een analoge opmerking geldt voor de overgang van 
opslagstructuur naar fysieke structuur. 

Een en ander is schematisch weergegeven in figuur 1.5. 


Specificaties ten aanzien van 


BETEKENIS 


GEBRUIK VAN 


(toegang tot) 
de gegevens 


MIDDELEN 


voor verwerking 
van de gegevens 


van de gegevens 


logische structuur 


opslagstructuur 


fysieke structuur 


Figuur 1.5 Fasering database-ontwerp. 
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Op deze figuur zullen wij in hoofdstuk 5 over normalisatie terugko- 
men, om duidelijk te maken dat normalisatie voor de logische struc- 
tuur een heel geschikt begrip is, maar ongeschikt kan (en in het 
algemeen zal) zijn voor de opslagstructuur vanwege het feit dat 
‘betekenis van gegevens! en 'gebruik van gegevens! tot tegenstrijdi- 
ge structuureisen kunnen leiden. 


1.5 DATABASE MODELLEN 


Als men een conceptueel schema wil opstellen en de bijbehorende 
manipulaties op de database wil vastleggen, doet zich uiteraard de 
vraag voor op welke wijze, met welk (taal)gereedschap men dit tot 
stand wil brengen. Dit gereedschap is eigenlijk zelf weer afhankelijk 
van de zienswijze die men heeft, met andere woorden afhankelijk van 
het database model. 


De drie bekende modellen zijn: 
- relationele model 

— netwerk model 

— hiërarchisch model. 


Over deze modellen zijn in de loop der jaren (verhitte) discussies 
gevoerd. Voor een korte inleiding zij verwezen naar (DATE, hfdst.3) 
en (LUN-REM, hfdst.10). 

In feite zijn deze modellen meer voorbeelden van bepaalde metho- 
den van aanpak dan van database theorieën. Een uitzondering kan 
misschien worden gemaakt voor het relationele model, althans voor 
bepaalde onderdelen daarvan. Want ook daarin geldt, dat veel van 
het gebodene te maken heeft met een methode. Met name geldt dit als 
sprake is van een zogeheten relational database, 

Met het bovenstaande wil niet gezegd zijn, dat bepaalde methoden 
niet erg nuttig zouden kunnen zijn. Maar om een methode te kunnen 
evalueren, dient men eerst wel een goede theoretische ondergrond te 
hebben. In dit boek is daartoe in het tweede deel een poging onder- 
nomen onder de naam van verzamelingsmodel. In grote lijnen kan 
men dit verzamelingsmodel zien als een theorie, waartoe het relatio- 
nele model de eerste stoot heeft gegeven, maar die dan verder con- 
sequent is opgebouwd met behulp van verzamelingenleer. In het 
derde deel van dit boek vindt dan een presentatie plaats van het 
netwerk model, met een evaluatie op basis van de voorgaande data- 
base theorie. 
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OPGAVEN 


In het algemeen leent de stof van dit inleidende hoofdstuk zich niet 
voor opgaven behalve het onderwerp relevante objecten en ken- 
merken'. 


1.1 Gegeven zijn van de organisaties onderwijsinstelling en handel- 
maatschappij onderstaande relevante objecten. 


organisatie relevante objecten 


a. onderwijsinstelling studenten 
| docenten 
vakken 
afdelingen 
examens 


b. handelmaatschappij leveranciers 
klanten 
artikelen 


Bedenk zelf relevante kenmerken bij elk van de objecten. 


1.2 Bedenk zelf relevante objecten en kenmerken voor de volgende 
organisaties : 
a. produktiebedrijf 
b. gemeente 
c. garagebedrijf. 


DEEL |I 
HET VERZAMELINGSMODEL 


2 WISKUNDIGE BASISBEGRIPPEN 


2.1 VERZAMELINGEN 


We beginnen met het ongedefinieerde begrip verzameling (Engels: 
set). Hierbij denken wij niet alleen aan verzamelingen zoals die van 
de natuurlijke getallen N, gehele getallen Z, rationele getallen Q en 
reële getallen R, maar vooral ook aan verzamelingen zoals: alle namen 
van ingeschreven studenten, alle combinaties van (registratienummer 
student, behaald cijfer) betreffende de uitslag van een bepaald ten- 
tamen. 

Een verzameling is geheel bepaald door zijn elementen. Hieruit 
volgt dat elk element precies eenmaal voorkomt in de verzameling. 
Men drukt dit ook wel uit door te zeggen dat in een verzameling 
geen duplicaten voorkomen. Een andere zaak is hoe wij de elementen 
van een verzameling beschrijven. Hierbij onderscheidt men beschrij- 
ving door enumeratie ('opsomming') en beschrijving met behulp van 
predicaten (beweringsvormen). Overigens kan een verzameling ook 
weergegeven worden met een 'geheel verbale omschrijving', zoals: 


Voorbeeld 2.1 


A = de verzameling van alle even gehele getallen tussen 7 en 15; 
met enumeratie: A = 18,10,14,12); | 
met predicaten: A = {glg € Z A g mod 2 = 0 A 7 < g <15}. D 


Opmerking. {8,10,14,12} en {8,14,8,10,12} zijn beide andere om- 
schrijvingen van dezelfde bovengenoemde verzameling A, die uit 4 
elementen bestaat. Uit bovenstaande moge duidelijk zijn, dat bij de 
beschrijving van een verzameling de volgorde der elementen er niet 
toe doet. 


Wij spreken van een eindige c.q. niet-eindige verzameling, naar ` 
gelang het aantal elementen eindig c.q. niet-eindig is. Zo is de ver- 
zameling A van voorbeeld 2.1 eindig en de verzameling N van de 
natuurlijke getallen niet-eindig. 

In dit boek zal verder uitsluitend van eindige verzamelingen spra- 
ke zijn. 
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Om het aantal elementen van een verzameling V aan te geven, 
wordt de notatie |V | of #V gebruikt. Zo is |A| = #A = 4 (A in voor- 
beeld 2.1). 

In de 'predicaten-weergave' van V, komt de uitdrukking 'g € Z' 
voor. Daarmee wordt bedoeld ''g is een element van de verzameling 
Z". 'g € Z' betekent: g behoort niet tot de verzameling Z. 

Het €-teken dient goed te worden onderscheiden van het c-teken 
(ook wel het c-teken). Dit laatste, het c-teken, wordt gebruikt om 
aan te geven dat een verzameling een deelverzameling is van een 
andere verzameling. V, is een deelverzameling van Vo, als elk ele- 
ment van V, ook tot Vo behoort. 

Notatie: v ë V, of Vi c Vo: 
Men ga zelf na dat de volgende uitspraken juist zijn (A in voorbeeld 
Ki) : 


(8,10) c A 
8EA 
(8) A 


maar de volgende onjuist: 
8 c A 
{8} € A 


Een deelverzameling V,, die niet gelijk is aan de ‘omvattende! ver- 
zameling V, noemen wij een echte deelverzameling van Vo. Hiervoor 
wordt soms de notatie V, z Vs gebruikt. 


De verzameling die geen enkel element bevat, noemen wij de lege 
verzameling. 

Notatie f. 

De lege verzameling is (bij afspraak) deelverzameling van elke ver- 
zameling. 


Definitie 2.1 De verzameling van alle deelverzamelingen van een 
gegeven verzameling V noemen wij de machtsverzameling (power set) 
van V. Notatie: P(V). o 
Voorbeeld 2.2 

Als gegeven is de verzameling A = {8,10,14,12}, dan is 

P(A) = {0,{8},{10},{12},{14}, {8,10}, {8,12}, {8,14}, {10,12}, 


(10,14),(12,14),(8,10,12),(8,10,14),(8,12,14),(10,12,14), 
(8,10,12,14)). 


Dus IP(A)| = 16 o 
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Het is eenvoudig in te zien dat uit |V| = n volgt IP(V)I = ” pa 


'Rekenen' met verzamelingen is mogelijk met behulp van de opera- 
ties verenigen, doorsnede nemen, verschil nemen. 


Definitie 2.2 De vereniging van de verzamelingen V, en V, is de 

verzameling, die bestaat uit precies alle elementen die tot minstens 

een van beide verzamelingen behoren. 

Notatie: LÉI U Vo D 

Definitie 2.3 De doorsnede van de verzamelingen V, en V, is de 

verzameling, die bestaat uit precies alle elementen die tot beide ver- 

zamelingen behoren. 

Notatie: Vi n Vo: D 

Definitie 2.4 Het verschil van de verzamelingen V, en V, is de 

verzameling, die bestaat uit precies alle elementen van Vy, die niet 

tot V, behoren. 

Notatie: V, * V,. n 
1 2 

Voorbeeld 2.3 


Gegeven: A = {8,10,12,14} en B = (x | x € Z A 11 š x < 20}. 
Dan is: 
A UB = (8,10.11.18.19 18,155 KOI ETAB, 19} 


A nB = {12,14} 
A. SB = (8:10) 
B ` À (41,15,15.16. En 19) m) 


2.2 BEWERINGEN 


In voorbeeld 2.1 hebben wij in de verzamelingsdefinitie {g | g € 
Z Ag div 2 =0A7 < g < 15} gebruik gemaakt van predicaten 
ofwel beweringsvormen. De uitdrukking 'g € Z Ag div 2 = 0 A 7 < 
g < 15' is een samengestelde beweringsvarm; die tot stand is geko- 
men door de beweringsvormen 'g € Z', 'g div 2 = 0'en 7 < g < 15' 
met elkaar te verbinden met behulp van 'A' (het 'en'-teken). 

Een beweringsvorm gaat over in een bewering als men aan de 
variabelen, die er in voorkomen een waarde toekent. Als men aan 
g de waarde 5 toekent, gaat de beweringsvorm 'g € Z' over in de 
bewering '5 € Z'. Bij de waardetoekenning g := 1,5, ontstaat de 
bewering '1,5 € Z'. De bewering '5 € Z' is waar, de bewering 
11,5 € Z' is niet waar. De bewering '5 mod 2 = 0' is onwaar, want 


1 


5 mod 2 is gelijk aan 1. De samengestelde bewering '5 € Z' en 
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5 mod 2 = 0' is dus niet waar. Dit laatste is een voor de hand liggen- 
de conclusie. Zij is bovendien in overeenstemming met de regels van 
de (wiskundige) logica. Deze regels maken het ons mogelijk te 'reke- 
nen' met beweringen, dat wil zeggen te bepalen of een samengestel- 
de bewering waar of onwaar is. 

In deze paragraaf zullen wij nu nader op deze regels ingaan. 
Daarbij worden beweringen symbolisch weergegeven met namen als 
b‚bl,b2. Waarden van beweringen worden weergegeven met zogehe- 
ten waarheidstabellen. 


Definitie 2.5 Als b een bewering is, dan is de ontkenning van b 
(notatie: lb; not b) de bewering, met waarden volgens tabel 1. 


Bt ib 
wio w = waar 
olw o = onwaar 


Tabel 1 - Waarden van lb. 
Nu volgt de definitie voor de 'en' verbinding. 
Definitie 2.6 Als b1 en b2 beweringen zijn, dan is de conjunctie 
van bl en b2 (notatie: bl ^a b2; bl and b2; bl en b2) de bewering, 
met waarden als in kolom 'b1 A b2' van tabel 2. 


En voor de 'of' verbinding de volgende 


Definitie 2.7 Als b1 en b2 beweringen zijn, dan is de disjunctie van 
bl en b2 (notatie: bl v b2; bl or b2; bl of b2) de bewering, met 


waarden als in kolom 'b1 v b2' van tabel 2. 


Tenslotte hebben wij voor de 'als...dan' verbinding 


Definitie 2.8 Als bl en bi beweringen zijn, dan is de implicatie met 
b1 als linkerlid en b2 als rechterlid (notatie: b1 = b2) de bewering 
met waarden als in kolom 'b1 > b2' van tabel 2. 


W = waar 
O = onwaar 


Tabel 2 - Waarden van conjunctie, disjunctie, implicatie. 


De waarden van bl A b2 en van bl v b2 zijn 'voor de hand liggend'. 
Dit geldt niet voor de implicatie. Zeker niet als men deze zou willen 


24 


zien als het weergeven van een verband tussen ‘oorzaak! (b1) en 
'gevolg' (b2). In het dagelijkse spraakgebruik denkt men bij als b1 
dan b2' vaak aan een oorzakelijk verband tussen bl en b2. Dit is 
uitdrukkelijk niet de bedoeling bij de implicatie in de logica. Met 

'b1 > b2' wil alleen het volgende tot uitdrukking gebracht zijn: "als 
bl waar is dan moet ook b2 waar zijn", hetgeen op hetzelfde neer- 
komt als "als b2 onwaar is, dan moet ook b1 onwaar zijn". Het is 
inderdaad niet moeilijk om (met behulp van een waarheidstabel) aan 
te tonen dat |b2 > |b1 equivalent is met bl > bi, 


Stel gegeven is het predicaat (de beweringsvorm) 


P(x) = x > 8 (x geheel getal) 


Dan zijn de beweringen P(5) en P(3) onwaar, en 
de beweringen P(9), P(17) en P(25) waar. 
Stel dat verder gegeven zijn de verzamelingen: 


A = {5,18,3,34,25,50} 
B = 19,17,25) 
C = 0,3). 


Dan zijn de volgende beweringen waar: 


Bi: er is (minstens) een element x € A, waarvoor P(x) waar is; 
B2: voor elk element x € B is P(x) waar; 
B3: er is geen enkel element x € C, waarvoor P(x) waar is; 


en de volgende beweringen zijn onwaar: 
B4: voor elk element x € A is P(x) waar; 
B5: eris een element x € B, waarvoor P(x) niet waar is. 


Bovenstaande beweringen kunnen ook worden weergegeven met zoge- 
heten kwantoren. Men onderscheidt : 

- de existentiële kwantor 3; met de betekenis: "er is een element..." 
- de al-kwantor V; met de betekenis: "voor elk element...". 

Dus: 


Bl: 3x € A [P(x)] 

B2: Vx EB [P(%)] 

Dä: (ax € C [P(x)]) 

BA: VxEA [P(x)] 

B5: x EBI IP} 
Uiteraard kunnen in een uitdrukking meerdere kwantoren voorkomen, 
zoals in onderstaande beweringen: 

B6: 3x € A [ay EB [y =x]] 


25 


B7: Vx € B [3y € A [y 2x)) 
BS: MEA (Vx € B [y = 2x]] 


Men ga zelf na dat B6 en B7 waar zijn en B8 onwaar. 


Twee existentiële kwantoren mogen altijd verwisseld worden, zonder 
dat de waarden van de bewering verandert. Zo is 3y € B [Ax € A 
[y = x]] equivalent met B6. Verwisseling van een al- en een exis- 
tentiële kwantor leidt echter in het algemeen niet tot een equivalente 
bewering. Zo is B7 niet equivalent met B8. 


2.3 FUNCTIES 


Voor de volgende definitie hebben wij het (ongedefinieerde) begrip 
geordend paar nodig. Als a en b elementen zijn dan is (a,b) de 
notatie voor het geordende paar, bestaande uit a en b in de gegeven 
volgorde. Wij zeggen dat (a,b) = (c,d) dan en slechts dan als a = c 
en b =d. 

Van het geordende paar (a,b) heet a de eerste coördinaat en b de 
tweede coördinaat. Formele notatie: C1(p) respectievelijk C2(p) is de 
eerste respectievelijk tweede coördinaat van paar p. Dus C1((a,b)) = 
aen C2((a,b)) = b. 


We zijn nu toe aan de definitie van het welbekende begrip functie. 
Vooraf zij erop gewezen, dat deze definitie (zoals verderop vrijwel 
elke definitie in dit boek) gegeven wordt in niet-formele en in for- 
mele vorm. Voor een 'rechtvaardiging' van deze 'dubbele vorm' zij 
verwezen naar het voorwoord. 

De nu volgende definitie van functie is niet erg gebruikelijk, 
maar voor ons doel wel geschikt (BROCK, 92). 


Definitie 2.9 

(niet-formeel) De verzameling f is een functie als 

a. elk element van f een geordend paar is 

b. f geen twee verschillende paren bevat waarvan de eerste 
coördinaten gelijk zijn. 


(formeel) De verzameling f is een functie p 
Vp € f [p is een geordend paar] 
A Vpl,p2 € f [C1(p1) = C2(p2) > pl = p2] o 


Opmerking. D wil zeggen: "is per definitie gelijk aan". 
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De verzameling van alle eerste coördinaten van een functie f heet het 
domein van f. 
Notatie: dom(f). 


De verzameling van alle tweede coördinaten van een functie f wordt 
het bereik van f, ook wel de range van f, genoemd. 
Notatie: rng(f). 


Als (x,y) € f, dan heet y het beeld van x onder f. 
Om deze 'beeldvorming' te benadrukken, wordt in plaats van (x,y) € 
f ook gebruik gemaakt van de equivalente notatie: (x, f(x)) € f). 
Voorbeeld 2.4 
Gegeven: 

fl = 1(a,5),(b,7),(0,3),(d,5)) 

f2 = {5,7,3,5} 

£3 = {(a,{5,7}),(b,7),(e, (3), (d,5) } 
Dan volgt hieruit: 


fl is een functie met dom(f1) = {a,b,c,d} en rng(fl) = {5,7,3} 
en fl(c) = 3; 

f2 is geen functie; 

f3 is een functie met dom(f3) = dom(fi) en rng(f3) = {{5,7},7, 
13),5) en f3(c) = 13). D 


Dikwijls wordt niet het begrip 'functie' maar alleen het begrip 
‘functie van A naar BI (ook wel ‘afbeelding van A naar B') gedefi- 
nieerd, waarbij A en B dan verzamelingen zijn. De Brock (loc.cit) 
wijst er terecht op dat met definitie 2.5 het niet nodig is (maar 
wel mogelijk) telkens twee verzamelingen expliciet te noemen, als 
men over een functie wil spreken. In ons geval, waar wij bij de 
formele opzet van databases veel gebruik zullen maken van het 
functiebegrip, biedt de gekozen aanpak beslist voordelen. 


Wij zullen nu 'functie van A naar B' definiëren. 


Definitie 2.10 

(niet-formeel) Als A en B verzamelingen zijn, dan is f een functie 
van A naar B als 

- f een functie is èn 

— het domein van f gelijk is aan A èn 

— het bereik van f een deelverzameling is van B. 

(formeel) Als A en B verzamelingen zijn dan: 


f is een functie van A naar B D 
f is een functie ën dom(f) = A ën rng(f) c B. 


Notatie: f: A-B D 
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Voorbeeld 2,5 
(fl en f3 uit voorbeeld 2.4) 


a. fl is een functie van {a,b,c,d} naar {5,7,3}, maar ook een 
functie van {a,b,c,d} naar {5,7,3,12,16}. 
b. f3 is een functie van {a,b,c,d} naar £5,7,3,15,7),13)). o 


Wij zijn nu toe aan een heel belangrijke klasse van functies, name- 
lijk de zogeheten verzamelingsfuncties (Engels: set-functions). 


Definitie 2.11 


(niet-formeel) Een functie {(a1,W1),(a2,W2),...,(ak,Wk)}is een 
verzamelingsfunctie, als elke Wi een verzameling is. 
(formeel) 


` A AQ $. 
F is een verzamelingsfunctie 2 
F is een functie èn 
Vx € dom(F) [F(x) is een verzameling] o 


Voorbeeld 2.6 
a. Gegeven: F = ((8,(1;2,3,4)),(b,(x,v/8ħ,(c,(1,k;x,£D) lu 
Dan volgt hieruit: 


F is een verzamelingsfunctie; 

dom(F) = (a,b,c); 

rng(F) = 111,2,3,4),(x,V,2),(1,k,x,f)); 
F(b) = dx.y,z) 


b. Gegeven: G = ((a,(1)),(b,(x))); H = ((a,1),(b,x)). 
Dan volgt hieruit: 


G is een verzamelingsfunctie; 

H is geen verzamelingsfunctie; 
dom(G) = dom(H); rng(G) # rng(H); 
G(8) = {1}; H(a) = 1 


c. ART = {(ano,{1...100}),(anm,‚charstring 20), 
(pr‚{10...500}), (gew, {1...300}), (vrd,{0...10000}), 
(KI, {rd ‚w ‚bl }) } 


waarbij charstring 20 de verzameling is van alle combinaties van 
maximaal 20 letters, cijfers of andere toegestane tekens. o 


Bij dit laatste geval c mag men uiteraard rustig bij de linkerkolom 
van onderstaand lijstje 'denken' aan de rechterkolom van dat lijstje. 
Dit maakt uiteraard het voorbeeld wiskundig niet meer waardevol, 
maar geeft wel een indicatie hoe grootheden 'uit de werkelijkheid' 
kunnen worden gerepresenteerd met exact gereedschap. 
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ART ARTIKEL 


ano artikelnummer 
anm artikelnaam 

pr prijs 

gew gewicht 

vrd voorraad 

kl kleur 


Opmerking. In de database-literatuur wordt het woord 'domein' 
(Engels: domain) gebruikt om de verzameling aan te geven die het 
beeld is van een element van het domein van een verzamelings- 
functie. In genoemde literatuur zal ART (ano) het domein van (het 
attribuut) ano heten. Dit is uiteraard erg verwarrend. Wij zullen 
het woord domein dan ook uitsluitend gebruiken in de (wiskundige) 
betekenis van het woord, namelijk verzameling van eerste coördina- 
ten (ofwel af te beelden verzameling). 


Tenslotte kunnen wij nu het begrip produkt van een verzamelings- 
functie invoeren. 


Definitie 2.12 

(niet-formeel) Als F de verzamelingsfunctie {(al,V1),(a2,V2),..., 
(ak,Vk)} is, dan is het produkt van F gelijk aan de verzameling 
die bestaat uit alle functies f waarvoor geldt: 


f = {(al,vl),(a2,v2),....(ak.vk) } met 
vi element van Vi E Sl GKI 


(formeel) Als F een verzamelingsfunctie is, dan is 
D 
het produkt van EF: 


{f | f is een functie èn dom(f) = dom(F) èn 
Va € dom(f) [f(a) € F(a)]) ` 


Notatie: M(F) D 


Het woord 'produkt' is hier geschikt gekozen, omdat het aantal 
elementen van M(F), dus IM(F)I gelijk is aan het produkt van 
IV1| * IV2| x... * IVkI. Er geldt dan ook voor elke (niet-lege) 
verzamelingsfunctie F: 


Stelling 2.1 (TI F) = Di dan en slechts dan als 
(3a € dom(F) [F(a) = 0]). 
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In woorden: als het produkt van een verzamelingsfunctie 
= {(al,V1),(a2,V2),...,(a3,V3) leeg is, dan is er een Vi leeg 
en omgekeerd. 


Een element van het produkt M(F) heet een tupel (Engels: tuple) 
van TI(F). 
Voorbeeld 2.7 


a. M(F) van F uit voorbeeld 2.6a bestaat uit 4 x 3 x 4 = 48 ele- 
menten. Een tupel van T(F) is bijvoorbeeld 


t = i(a,1),(b,v);(e:x)). 

b. H(G) van G uit voorbeeld 2.6b bestaat uit precies één element en 
wel het element 
((a,1),(b,x)). 
Let wel: M(G) = (((a,1),(b,x))). 

c. Onderstaand is een deelverzameling van T(F) van F uit voorbeeld 
2.2a weergegeven: 


= (1&;1) Ch ig) Ord, ta, LK Ob, SH, Ce EE, Les @) ,Cb.,x), (e x) }, 
{(a,3),(b‚2),‚(e,k)},{(a,1),(b,z),(e,1)}}e WF). 


Zo'n deelverzameling van een produktverzameling kan eenvoudig 
worden weergegeven met behulp van een tabel. Zo is de tabel- 
weergave van Y als volgt: 


aM ° 


en 
N N OM N < 
SÉ MER N 


Wil men een functie 'beperken' tot een deei van het domein, dan is de 
volgende definitie van belang. 


Definitie 2.13 

(niet-formeel) Als f een functie is en X is een deelverzameling van 
het domein van f, dan is de restrictie van f tot X de functie, die 
bestaat uit de paren (x,y) van f, waarbij x een element is van X. 
(formeel) Als f een functie En en X c dom(f), dan is 


de restrictie van f tot X Dix.) | (xk;y) € f Ax € X). 
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Notatie: f/X o 


En voor een soortgelijke 'beperking' van een deelverzameling van het 
produkt van een verzamelingsfunctie: 


Definitie 2.14 
(niet-formeel) Als F een verzamelingsfunctie is en X een deelverza- 
meling van het domein van F en Y een deelverzameling van het pro- 
dukt van F, dan is de projectie van Y op X de verzameling van de 
tot X gerestricteerde functies van Y. 
(formeel) Als F een verzamelingsfunctie is èn X c dom(F) èn 
Y € M(F), dan is 
D 
de projectie van Y op X ` (f[X| f € Y). 


Notatie: Y//X. D 


Voorbeeld 2.8 


Bij f respectievelijk Y van voorbeeld 2.7a respectievelijk c: 


f/Ta,b) = ((a,1),(b,Vv)); 
fflal = Wa.b)); 


Y//Ta,b.) 5:1f(a,1),(b.V)).1(8,D:,(b32)0; (Ca, 4) ; (b;>) }, 
((a,3)(b,z))). 
yI ti (85139; a KSE 


In tabelvorm luidt ditzelfde voorbeeld voor Y |[{a,b} en YI[ {a}: 


a ik 
Kg 
Y//{a,b} = L 
4 x 
3 Z 
a 
SE 1 
Y//fa) $ 4 
3 


Uit de bovengenoemde definities volgt direct, ten aanzien van de 
restrictie: 
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Stelling 2.2 Als f een functie is en X c dom(f), dan 

a. f/X is een functie en f/X c f. 

b. dom(f/X) = X èn vx € X[f/X(x) = f(x) 1. 

c. EI = 9. D 


Het zal in het vervolg uiterst nuttig blijken, te kunnen beschikken 
over het volgende begrip. 


Definitie 2.15 

(niet-formeel) Een verzamelingsfunctie F = ((al,V1),(a2,V2),..., 
(ak,Vk)} is regulier als elke Vi niet leeg is. 

(formeel) Als F een verzamelingsfunctie is, dan is 


- 


F is een reguliere verzamelingsfunctie 
F f f èn Va € dom(F) [F(a) # 0]. o 


Een reguliere verzamelingsfunctie heeft de volgende ‘geschikte! 
eigenschap: 


Stelling 2.3 Als F een reguliere verzamelingsfunctie is en X c 
dom(F), dan geldt: 


(MF))//X = (F/X). D 


In 'woorden' luidt deze stelling: de projectie van het produkt van 
een reguliere verzamelingsfunctie F op X is gelijk aan het produkt 
van de restrictie van F tot X. Het doet er dus niet toe of men 
eerst de verzamelingsfunctie 'beperkt' en dan het produkt neemt 
of omgekeerd, de 'beperking' pas tot stand brengt nadat het 
produkt gevormd is. 

Nogmaals zij opgemerkt dat dit 'goed gaat', omdat de voorwaarde 
is gesteld dat F regulier is. (Voor de liefhebbers: dit is wel een 
voldoende, maar geen nodige voorwaarde voor stelling 2.3.) Maar 
deze regulariteit is nu juist hetgeen overeenkomt met ons intuïtieve 
beeld van de attributen, die wij willen representeren. Immers, het 
is niet voorstelbaar, dat wij attributen zouden willen representeren, 
waar geen enkele waarde aan kan worden toegekend. Eenwaardige 

attributen kunnen wij ons wel voorstellen en zijn dan ook in het 
formele model toegelaten. Overigens zullen wij van eenwaardige attri- 
buten geen gebruik maken, omdat er geen enkele informatie aan kan 
worden ontleend. In feite zullen wij dus alleen te maken hebben met 
attributen, waaraan minstens twee verschillende waarden kunnen 
worden toegekend. 
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OPGAVEN 


2.1 Gegeven zijn de verzamelingen A,B,C,D,E. 
A = {1,2,3,4,5}; B = 12,4,6,8); C š {3,4,7, 
D = {7,8,10,13}; E = f. 


a. Geef de elementen van: 


9); 


Ví =A UB V, = (ANCJU(BNC) Vo =D UE 

V, = AnB Ve" (AUB) U C LÉI, s D xE 

V, = A nD V. = A U (BUC) Va ED 

V, = (AUB) n c Vg =D n P Y a F (ASB) x C 
b. Bepaal: 


IA U. BI; IAI + IB 151; ID BI: 


c. Welke van de volgende beweringen zijn waar? 


Cl TREM c5. (ANB)ND = AN(BSD) 
C2. TE AUG cü, E €. À 
e3. {{2}}e B c7. EEA 


c4. (AnB)UD = (AUD)N(BUD) c8. BNC € A 

69. AIT EN At adkat mad de Dante 9) c B 
el0. tt EN At > Ot mod 2=0aAt < 913.B 
cil. (tit EN at > 0 a (mod 2 = 1 vt < 9} >B 
c12. 3x € A [x is even] 

cll, Vx € A LI EB EVERS 

c14. Jy EB [Vx CA tyexll 


d. Beschrijf alle elementen van P(B) en van P(B n C). 
e. Toon, dat als IVI = n, geldt: IP(V)I = We 


f. Welke van de volgende beweringen zijn waar? 
fL. (1) c P€6A) f3. P(BNC) = P(B) N P(C) 
f3. (08) SPOR f4. {E} € P(A) 


CH Ze $ 
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Van functie f is gegeven: 

dom(f) = {a,b,c}; 

fla) = 3; f(b) = f(c) = 3 f(a) 

Geef een beschrijving van f (enumeratie). 


. Van functie g is gegeven: 


dom(g) = (p,q,r,s); 
Vx € dom(g) [g(x) = x] 


Geef een beschrijving van g (enumeratie). 


. Gegeven h: x > x? +3 | x € {3,5,7}. 


Geef een beschrijving van h (enumeratie). 


2.3 Ga de juistheid van stelling 2.2 na. 


2.4 Gegeven zijn de volgende zeven functies: 


F1 
F2 
F3 
F4 
F5 
F6 
F7 


a. 


= {(kleur, {fout , goed }) , (produkt , (fout , goed }) ). 

= ((mnr,11,2,3)),(nm,itf,st)),(kl,(w,rd))). 

= (8, 1),(B511,2,3)1),(0:(4,5)),(4,(2;1,3D), 

= i(gew,(5)),(nm,(a,b)),(kl,(w,zw)),(pr,(10,15,20))). 
= i(gew,10)),(nm,fa,b)),(kl,(w,zw)),(pr,(10,15,20))). 
= ((gew,0),(nm,(a,b)),(kl,(w,zw)),(pr,(10,15,20))). 
= 1(a,(5,7/),(b,(p,4,r)),(e,((p,q),1q,r),(p,r)D). 


Geef: dom(F5); rng(F5); dom(F1); rng(F1); dom(F7); 
rng(F7). 


. Geef: F3(a); F2(nm); F5(gew); F6(gew). 


. Vul in (indien mogelijk): 


Fac...) 5 (Est); FoC...) = {15,10,20}; FI(...) = fout: 
FIC.)  (pih FH... =de FSE...) = O; 
112, Ida 


— 
GA) 
N; 
— 
H 


. Bepaal: F1/(kleur); 


F4/Tgew,kil); F4/Tkl,nm); 
F5/igew,kl); F5/{kl,nm}. 
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e. 


g. 


Ga voor elke functie na of het een verzamelingsfunctie is. 
Zo ja, geef het aantal elementen van het produkt van de 
desbetreffende verzamelingsfunctie en geef (zo mogelijk) 
twee elementen van dit produkt. 
Bepaal: M(F4)//(gew,ki); M(F4 /(gew,kli). 
TM(F6)//Tgew,kl); M(F6/(gew,ki). 
MF4)//(ki,pr); M(F4/(kl,pr). 
M(F6)//(kil,pr)j; M(F6/1kl,prj). 


t € M(F2) 

Welke van onderstaande beweringen is waar? 
gl. t(mnr) = t/ (mnr) 

g2. t(mnr,nm) = t/{mnr‚nm} 

g3. (m,t(mnr)) = t/(mnr). 


3 TUPELTYPE EN RECORDTVPE; 
TABELTYPE EN FILETYPE 


3.1 TUPELTYPE EN RECORDTYPE 


Elk individueel object, dat actueel van belang is, dus elke actuele 
objectoccurrence, zullen wij de in database gepresenteerd willen 
zien. Deze representatie zal dan de vorm hebben van een verza- 
meling waarden van relevante attributen. Zo zullen bijvoorbeeld 
van een patiënt in de database liggen opgeslagen de waarden van 
de attributen: pnr (patiëntnummer), nm (naam), adr (adres), 
wpl (woonplaats), gbd (geboortedatum), gsl (geslacht). Het is 
gebruikelijk zo'n verzameling bij elkaar behorende waarden een 
record te noemen. Bij een object kunnen vele mogelijke actuele 
objectoccurrences horen. In programmeertalen als Pascal wordt 
dan ook het zogeheten recordtype gebruikt. Zo'n recordtype is 
de verzameling van alle mogelijke records, dus van alle mogelijke 
combinaties van attribuutwaarden. Wij zullen zien dat record- 
typen in feite heel bijzondere gevallen zijn van zogeheten tupel- 
typen. 

Een tupeltype is de verzameling van alle mogelijks tupels. En een 
tupel is dan de representatie van een object-occurrence. Zo kunnen 
de gegevens van een bepaalde patiënt als volgt met een tupel ti (een 
functie) worden weergegeven: 


tl = ((pnr,15),(nm,p.jansen), (adr. rondweg 10), (wpl,eindhoven), 
(gbd,250116),(gsl,m)). 


En van een andere patiċnt zal onderstaand tupel t2 de actuele toe- 
stand weergeven: 


t2 = i(pnr,27),(nm,a.brakes),(adr,woertlaan 15),(wpl,nuenen), 
(gbd,350310),(gsi,v)). 
Een en ander leggen wij nu vast in de volgende definitie. 


Definitie 3.1 | 
(niet-formeel) Een tupeltype is een niet-lege verzameling functies, 
waarvoor geldt, dat zij allen hetzelfde domein hebben. 
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(formeel) De verzameling T is een tupeltvper 


T ff èn 
vf € T [fis een functie Af f 0] èn 
Vf1,f2 € T Ldom(fi) = dom(f2)). n 


Zo is Y van voorbeeld 2.7c een tupeltype. Uit dit voorbeeld is ook 
duidelijk, dat een tupeltype eenvoudig in tabelvorm kan worden 
weergegeven. Het gemeenschappelijke domein fungeert dan als tabel- 
hoofd. Vanwege de gemeenschappelijkheid van het domein, zullen wij 
ook spreken van het domein van een tupeltype, en daarmee bedoelen 
het gemeenschappelijke domein van de functies van dit tupeltype. 
Een element van het domein van een tupeltype wordt een attribuut 
van dit tupeltype genoemd. Het genoemde voorbeeld Y is, zoals we 
zagen in voorbeeld 2.7c, een deelverzameling van het produkt van 
een verzamelingsfunctie. Dit is niet toevallig. Het is namelijk een- 
voudig aan te tonen, dat bij elk tupeltype een verzamelingsfunctie 
kan worden gedefinieerd zodanig dat het onderhavige tupeltype een 
deelverzameling is van het produkt van genoemde verzamelings- 
functie. Een element van een tupeltype is dus een tupel. 

Voor het genoemde voorbeeld Y kan F van voorbeeld 2.6a als 'bij- 
behorende! verzamelingsfunctie fungeren, maar ook 


= LCA ES GII (DARI VENLO Gk t; b. 


Het verschil tussen F en F' zit uiteraard niet in het domein, maar 
in de beelden van het domein (dus de waardenverzameling behoren- 
de bij elke attribuut). 

Verder kan nog worden opgemerkt dat F' de 'kleinste' bij Y beho- 
rende verzamelingsfunctie is, waarmee wij bedoelen dat F' de kleinst 
mogelijke waardenverzameling per attribuut bevat zodanig dat Y < 
M(F'). Het is niet moeilijk in te zien dat bij elk tupeltype X een 
kleinste verzamelingsfunctie FX bestaat. 

Aangezien een tupeltype wordt gebruikt als de representatie van 
de verzameling mogelijke objectoccurrences, ligt de volgende naam- 
geving voor de hand. Een bij een tupeltype behorende verzamelings- 
functie (in zojuist geschetste zin) wordt ook wel een objectkarakte- 
risering genoemd. Uiteraard kunnen wij dan verder ook spreken van 
de kleinste objectkarakterisering van een tupeltype. 


Beschouwen we nogmaals het reeds eerder genoemde voorbeeld Y 
van een tupeltype en de daarbij behorende objectkarakterisering F'. 
We moeten dan vaststellen, dat ofschoon F' de kleinste bijbehorende 
objectkarakterisering is, Y toch niet gelijk is aan het gehele produkt 
M(F'). Met andere woorden: M(F') bevat tupels, die niet in Y voorko- 
men. Men kan het ook zo stellen: er zijn blijkbaar tupels in M(F') die 
niet als representanten van ‘bijbehorende! objectoccurrences kun- 
nen optreden, om de eenvoudige reden dat deze objectoccurrences 
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niet mogelijk zijn. 

Hoe kunnen nu tupels worden uitgesloten? Door ze allemaal apart 
te noemen. Maar deze methode zal over het algemeen onwerkbaar 
zijn, omdat het gaat om zeer grote aantallen. Hiervoor hebben wij 
dan ook de aanpak met behulp van de zogeheten constraints, ook wel 
genoemd de integrity-constraints. 

Nu kunnen wij de constraints nog in diverse klassen onderschei- 
den. Deze klassen komen successievelijk aan bod in dit en de vol- 
gende hoofdstukken. Wij beginnen nu met de zogeheten tupelcon- 
straint. 


Een tupelconstraint geeft weer waaraan de combinatie van attribuut- 
waarden van een tupel moet voldoen. Een tupelconstraint is dus een 
predicaat over het produkt van een objectkarakterisering. 

Ter verduidelijking het volgende voorbeeld. 
Voorbeeld 3.1 


Gegeven zijn de verzamelingsfuncties F en ART (van voorbeeld 
2. Dä en 2. Gei: 


F - ((a,(1,2,3,4)),(b,(x,V:2)),(e,(1,k,x,f)) 8 
ART = ((ano,(1...100)),(anm ,charstring 20),(pr,110...500)), 
(gew,11...300)),(vrd,10...10000)),(kiI,(rd,w,bIb)). 


De tupelconstraints C1, C2 en C3 worden nu als volgt gedefinieerd. 


Clt) := [(t(a) = 1) = t(b) f y A t(c) = kl over de verzameling 
(EA, 
I (t(ano) < 75) > t(gew) > 20) over de verzameling MART); 


[t(pr) x t(vrd) < 100000] over de verzameling MART). 
D 


C2ét): 
Coet): 


Een tupel t van T(F) zal voldoen aan de tupelconstraint C1, als, 
in geval attribuut a de waarde 1 heeft, attribuut b een waarde 
ongelijk y heeft en attribuut c de waarde k. De tupels {(a,1), 
(b,x),(c,k)) en ((a,2),(b,v),(c,1)) voldoen dus aan C1, maar 
tupel ((a,1),(b,y),(c,k)) niet. | 

Door C1 worden 10 tupels van TI(F) 'uitgeschakeld' (men ga dit 
na! ). 


Stel constraint C4 is als volgt gedefinieerd: 


C4(t) := [t(a) Z 2] over T(F), F als in voorbeeld 3.1. 


Het merkwaardige aan CH is, dat deze constraint overbodig is, als in 
plaats van F(a) = 11,2,3,4) zou worden gesteld F(a) = {1,3,4}. Met 
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andere woorden: C4 is eigenlijk geen constraint op tupelniveau, maar 
op een niveau 'lager', op attribuutniveau. C4 zou men dan ook 
gevoeglijk een attribuutconstraint kunnen noemen. Meer algemeen: 
een attribuutconstraint geeft aan waaraan de waarde van een attri- 
buut (los van andere attributen) moet voldoen. 

Wij spreken nu van een echte tupelconstraint als deze geen attri- 
buuteonstraint bevat. C4 is een duidelijk voorbeeld van een niet- 
echte tupelconstraint. Niet-echte tupelconstraints kunnen echter ook 
in meer ‘verhulde! vorm voorkomen, zoals constraint C5, die als volgt 
is gedefinieerd: 


C5 := ((t(a) € (1,2) 4 t(b) = x) A(t(a) Et{3,4} > t(b) É y)]). 


De tupelconstraint C5 bevat de attribuutconstraint C6 en de echte 
tupelconstraint C7, waarbij 


C6 := (t(b) # y] (dus V £ F(b)) en 
C7 := itfa) € t(1,2) = t(b) = x]. 


(C5, C6 en C7 constraints over eerder genoemde T(F).) 


Aangezien C2 en C3 betrekking hebben op dezelfde verzameling, 
kan men ook spreken van de conjunctie C2 A C3 als één constraint. 
Door van eenzelfde produkt de conjunctie te nemen van alle con- 
straints over dat produkt, kan men in feite spreken over een 
karakteriserend tupelconstraint over dat produkt voor het gegeven 
tupeltype. Gegeven een tupeltype T ligt dus vast: de bijbehorende 
kleinste objectkarakterisering K en een bijbehorende karakterise- 
rende tupelconstraint TC, zodanig dat 


(A) itl t € M(K) ATOMI? st, 


Hierbij moet nog wel worden opgemerkt, dat TC op equivalentie na 
vastligt. Hiermee bedoelen wij dat TC vervangen kan worden door 
TC', mits de uitdrukking sub A waar blijft: met andere woorden 
TC(t) e TC'(t) voor alle t € M(K). 

Voorbeeld 3.2 


We zagen al dat bij Y van voorbeeld 2.7c als kleinste objectkarakte- 
risering hoort 


Ris fla, (1,3, 4D); (b, {xy B, (e, tel, 


Een karakteriserende tupelconstraint over M(F') voor Y is bijvoor- 
beeld: 
TC1(t) = ((t(b) = t(c) et(a) > 3) A (t(e) =k et(a) = 3) A 
(t(b) £ z > t(c) = x)] 


(voor nadere toelichting zie onderstaande tabel) 


maar ook de daarmee equivalente 
TC2(t) = [(t(a) =1 > (t(b) É x At(e) # k)) A 
(t(b) = y » t(c) #1) 
(t(a) = 3 > t(b) é {x,y} a t(e) € {1,x}) A 
(t(a) = 4 > t(b) £ {z,y} a t(e) é (1,k))]. 


Met behulp van onderstaande tabel, waarin alle tupels van M(F'), 
moge duidelijk zijn dat inderdaad geldt: Y = {t| t € M(F') A 
TCI(t)). Hierbij is 


C1(t) :- [t(b) = t(e) et(a) > 3] 
C2(t) := [t(e) =k et(a) = 3) 
C3(t) := [t(b) f z > t(ce) = x]. 


Een streepje in een C-kolom wil zeggen, dat het tupel niet voldoet 
aan de desbetreffende constraint. 
De lezer ga zelf de juistheid van het gestelde na met TC2. 


8. b e ICi C2 Gasa Db c IkbE C2 LIER bet C2 C3 

. £. | ect "7 e d me: — SCH Ro zb _ 

Ta EE KEEN ĦA kO 5 
KR Wa s f Se o RE x xl 

; ç. véi? E Sen VL w m 5 4 y ET - 

1. VAR Pare WR e y Ri- - - 

. Ae e Lé y XK = 

ZC SS e Walk ie 

+ s j - B £ kK 4 z kl- - 

Ë z x] 9:32. X % t e Sir 


D 


In het algemeen zal en kan het niet zo zijn dat vanuit een gegeven 
tupeltype T de bijbehorende kleinste objectkarakterisering en een 
bijbehorende karakteriserende tupelconstraint wordt 'gezocht'. Inte- 
gendeel: uitgangspunt zal zijn een objectkarakterisering (attributen 
met bijbehorende waardenverzamelingen), waar bovenop dan de 
tupelconstraint(s) worden gedefinieerd. Hiermee ligt dan uiteraard 
een tupeltype vast. 
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Voorbeeld 3.3 
Gegeven de objectkarakterisering 

K = ((2,(1,2,3,4)),(b,1x,V,Z2)),(ce,11,k,x,f)))- (voorbeeld 2.6a) 
èn de constraints C1 en C2 over T(K): 

C1(t) = [(t(a) = 1) > (t(b) f y A(t(e) = x vt(e) = 1))] 

C2(t) [(t(a) #1) > (t(b) = y At(c) f x)) 


dan ligt hiermee vast het tupeltype T, onderstaand weergegeven in 
tabelvorm. 


a b c 

1 x 

1 Ce 1 

1 Z X 

1 Z 1 

2 y 1 

2 y k 

> y f 

3 y 1 

3 y k 

3 y f 

4 y 1 

4 y k 

4 y f n 
Voorbeeld 3.4 
De objectkarakterisering ART en de constraints C2 en C3 van 
voorbeeld 3.1. 
Het tupeltype T-ART waarvoor geldt 

T-ART = (tl t € MART) A (C2  C3)(t)} 
bevat nu zeer vele tupels. Het is uiteraard praktisch onmogelijk x 
T-ART in tabelvorm weer te geven. o x 


Het is theoretisch denkbaar dat een tupeltype gelijk is aan het pro- 
dukt van de bijbehorende kleinste objectkarakterisering, dus een 
tupeltype zonder enige tupelconstraints (formeel: TC = true). En dit 
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is dan gelijk aan het record-type in (de programmeertaal) Pascal. 
Het Pascal record-type is dus wel een heel bijzonder geval van het 
tupeltype. 


Nu wij kunnen beschikken over waardenverzamelingen van het tupel- 
type, kunnen wij variabelen declareren van een tupeltype. 


Voorbeeld 3.5 
Met: 
var PUNL FUN? L T; 
A: TAART 
endvar; 


worden variabelen gedeclareerd van het type T (voorbeeld 3.3) 
respectievelijk T-ART (voorbeeld 3.4). Met 


FUNI.a := 3; FUNI.b := y; FUNI.C := x 


wordt dan bewerkstelligt dat de variabele FUN1 een bepaalde waarde 
krijgt. Met FUN2 := FUNI krijgt FUN2 dezelfde waarde. 


In dit voorbeeld wordt uitgegaan van een syntax à la Pascal. De 
componenten van de variabelen zijn de attributen van de bijbehoren- 
de tupeltypen. o 


3.2 TABELTYPE EN FILETYPE 


Van een bepaald object is meestal niet precies één objectoccurrence 
actueel, maar is sprake van meerdere actuele objectoccurrences, 
bijvoorbeeld meerdere artikelen. De representatie van een verzame- 
ling V1 actuele occurrences van eenzelfde object kan uiteraard 
geschieden in de vorm van een deelverzameling van een tupeltype. 
Voor de representatie van een andere verzameling V2 actuele 
occurrences van hetzelfde object op een ander moment kan dan een 
andere deelverzameling worden genomen van hetzelfde tupeltype. 


Voorbeeld 3.6 


Onderstaand worden in de vorm van twee tabellen verschillende deel- 
verzamelingen D1 en D2 van het tupeltype T-ART (voorbeeld 3.4) 
gegeven. ; i | 
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ano anm pr gew vrd kl 

5 stoel 25 21 153 rd 

stoel 27 29 61 rd 

PET 93:45: tafel. ; 132 42 18 e 
18 bank 98 38 12 W 

ano anm pr gew vrd kl 

17 kast 215 112 18 rd 

7 stoel 27 29 61 rd 

D2 = 5 stoel 25 21 153 rd 
93 tafel 132 42 23 Ww 

78 bank 98 38 17 W 


D1 en D2 in bovenstaand voorbeeld kunnen ook worden gezien als 
deelverzamelingen van twee verschillende tupeltypen, mits de 
domeinen (attributenverzamelingen) van beide gelijk zijn. Aange- 
zien een niet-lege deelverzameling van een tupeltype per definitie 
weer een tupeltype is, kunnen D1 en D2 zelfs gezien worden als 
twee verschillende tupeltypen met uiteraard eenzelfde domein. Twee 
tupeltypen met eenzelfde domein noemen . wij domeinverwante tupel- 
typen of kortweg verwante tupeltypen. Aangezien een tabel een 
niet-formele weergave is van een tupeltype, kan op niet-formele 
wijze gesproken worden van verwante tabellen, als zij hetzelfde 
tabelhoofd hebben. 


De gebruikelijke benaming voor een (deelverzameling van een) 
tupeltype als representatie van de verzameling actuele occurrences 
van een object is file (bestand). De verzameling actuele occur- 
rences van een object kan (in de loop der tijd) erg wisselend zijn. 
Analoog aan het eerder genoemde recordtype wordt in program- 
meertalen als Pascal dan ook het zogeheten filetype gebruikt. Wij 
zullen ook hier weer zien, dat filetypen heel bijzondere gevallen 
zijn, en wel van zogeheten tabeltypen. 


Definitie 3.2 
(niet-formeel) Een tabeltype is een verzameling verwante tabellen 
of een verzameling verwante tabellen verenigd met de verzameling, 
die bestaat uit de lege verzameling. 

(formeel) De verzameling TT is een tabeltype 


TT = V of TT = 191 0 V, 


Ile, 
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waar V een verzameling verwante tupeltypen is. o 


Een element van een tabeltype heet een tabel. Om dit formele begrip 
'tabel' te onderscheiden van het eerder gebruikte niet-formele 
begrip 'tabel' (eerste maal in voorbeeld 2.7), zou men voor dit laat- 
ste steeds een andere benaming, bijvoorbeeld 'tabelfiguur', kunnen 
gebruiken. In dit boek wordt echter geen gebruik gemaakt van zo'n 
aparte benaming, omdat het nogal gekunsteld is en uit de context 
wel duidelijk is of sprake is van het formele dan wel het niet-formele 
begrip. 


Een tabel is de formele representatie van de verzameling actuele 
occurrences van een object, dus de representatie van een bestand 
op een bepaald moment. Als de lege verzameling tot een tabeltype 
behoort, betekent dit, dat het te representeren bestand leeg kan 
zijn. Een leeg bestand hoeft uiteraard niet tot de toegestande moge- 
lijkheden te behoren. 


Voorbeeld 3.7 


Onderstaand worden drie voorbeelden van tabeltypen gegeven, TT1, 
EES, 113. 


1. TT1 = (P,M(F),X,T), waarbij F,X,T in de voorbeelden 2.6a, 
_2.7e en 3.3 voorkomen. 
2. TT2 = TTIS{M(F)}. (Let wel: TT2 = {0,Y,T}en TTIAN(F) = TTI) 


3. TT3=TT1U {{{(a,5),(b,y),(c‚x) y, 
((a,4),(b,z),(c,f))), 
(((a/5776b;2z);(0,8) ); 
((a,4),(b,z),(c,f)), 
((a,3),(b‚y),(e, DD}. o 


Aangezien verwante tupeltypen hetzelfde domein, dus dezelfde attri- 
buten hebben, spreken wij van het domein, de attributen van een 
tabeltype en bedoelen dan daarmee het gemeenschappelijke domein 
van de verwante tupeltypen van dit tabeltype. 

Bij elk tabeltype TT kan (minstens) éen tupeltype T worden 
gedefinieerd zodanig dat elk van de verwante tupeltypen van TT een 
deelverzameling is van T. Zo'n tupeltype T noemen wij dan een 
karakteriserend tupeltype voor TT. 


Voorbeeld 3.8 


Onderstaand worden enkele voorbeelden van karakteriserende tupel- 
typen gegeven. 
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Tabeltvpe Karakteriserende tupeltvpen 
(zie vb. 3.7) 
Ke GERA MF) (vb. 2.78) 
b. UT2 bile TCF) (yb. 2;Ta) 
bis. V (00, 2 3y U Y (vb; 2.10) 
C. TT3 c.1. WE) (vb. 2.7a) U 


(((2,5),(b,V):(c0,X)), 
((a,5);(b.z);Go;D) k). 
c.2. T(G), waarbij 
Q = ((a,X4,2,34;5  (b>iy x s SA, 
Edd Hp ee wa a 


Twee verschillende karakteriserende tupeltypen van eenzelfde tabel- 
type hebben uiteraard hetzelfde domein. Als TT een tabeltype is, 
noemen wij de verzameling tupels 


MT = (tt ETTET)? 


het kleinste karakteriserende tupeltype van TT. Merk op dat MT 
inderdaad een karakteriserend tupeltype van TT is. Er geldt dus 
voor elk karakteriserend tupeltype KT van TT: KT >MT. 

Zois T U Y het kleinste karakteriserende tupeltype van tabel- 
type TT2 (vb. 3. 8b). 

In het algemeen zal niet elke deelverzameling van het kleinste 
karakteriserende tupeltype MT van een tabeltype TT tot dit tabel- 
type behoren. 


Voorbeeld 3.9 
Gegeven is tabeltype TT4 = (0,E1,E2,E3,E4) met Ei (in tabelvorm): 


a AE a. a Q...Q 

I S X t y 
El = 4 2 Ned ek * x. `x 

3 XX 

£ a f 1 
"a 2 f E4 = L k 
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Dan is het kleinste karakteriserende tupeltype MT van TT4 (in 
tabelvorm): 


MT 


H 
> Aa NN 
BER MR e OGM 
HE fit, en B mW 


Er zijn dus in totaal 2! = 128 deelverzamelingen van MT. Van deze 
128 behoren er slechts vijf tot het tabeltype TT 4. o 


Hoe kunnen nu deelverzamelingen van MT (dus elementen van 
P(MT)) worden uitgesloten? Evenals bij uitsluiting van tupels bij de 
definitie van een tupeltype, moet ook hier gezegd worden dat uit- 
sluiting van deelverzamelingen via de weg van enumeratie een 'onbe- 
gonnen zaak' is. Wij zullen het ook hier weer doen met behulp van 
integrity constraints en wel met de klasse van de zogeheten tabel- 
constraints. 

Een tabelconstraint geeft weer waaraan de combinatie van tupels 
van een tabel moet voldoen. Een tabelconstraint is dus een predicaat 
over de machtsverzameling van een tupeltype. 


Voorbeeld 3.10 

De constraints C1, C2: 
C1(D) := [#(D) < 5] over P(T) (Tin vb. 3.3); dus D € P(T). 
C2(D) := (vti,t2 € D [t] (a) = t,(a) = t; = t,1) over P(MT) 


(MT in vb. 3.9); dus D € P(MT). 
P(T) bevat 21" = 8192 deelverzamelingen. Door constraint C1 worden 
hiervan 5812 'uitgeschakeld'. o 


Evenals bij tupelconstraints maken wij bij tabelconstraints onder- 
scheid tussen echte en niet-echte tabelconstraints. Een echte tabel- 
constraint is een constraint die geen constraint van 'lagere orde', 
dus een tupel- of attribuutconstraint, bevat. Stel C3 is als volgt 
gedefinieerd: C3(D) := [Yt € D[t(a) = 2 > t(c) = f] over P(MT) 
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(MT in vb. 3.9), dan is C3 geen echte tabelconstraint, maar een 
echte tupelconstraint. 


Analoog aan de karakteriserende tupelconstraints bij een tupeltype 
spreken wij ook van de karakteriserende tabelconstraints bij een 
tabeltype. Gegeven een tabeltype TT ligt dus vast: het kleinste 
karakteriserende tupeltype MT en een bijbehorende karakteriseren- 
de tabelconstraint TTC zodanig dat: 


TT = (D| D € P(MT) ATTC(D)J). 


Evenals bij tupeltypen zal over het algemeen niet de bedoeling zijn 
dat bij een tabeltype TT het bijbehorende kleinste karakteriserende 
tupeltvpe en een karakteriserende tabelconstraint worden 'gezocht'. 
Ook hier zal het uitgangspunt niet zijn een tabeltype, maar omge- 
keerd een (karakteriserend) tupeltype, waar bovenop dan tabelcon- 
straints worden gedefinieerd. En hiermee ligt dan uiteraard een 
tabeltype vast. 


Voorbeeld 3.11 


Gegeven tupeltype MT van voorbeeld 3.9 en de karakteriserende 
tabelconstraint C2 van voorbeeld 3.10. 
Het tabeltype TT5 wordt gedefinieerd door: 


TT5 = (DI D € P(MT) A C2(D) }. 
TT5 bevat 54 elementen: f, 7 elementen met precies één tupel, 


18 elementen met precies 2 tupels, 20 elementen met precies 3 tupels, 
8 elementen met precies 4 tupels. 


Het is ook duidelijk dat voor TT4 van voorbeeld 3.9 geldt: TT4 c 
TT5 en beide hebben hetzelfde kleinste karakteriserende tupeltype. 
o 


Voorbeeld 3.12 


Gegeven tupeltype T-ART van voorbeeld 3.4 en de karakteriserende 
tabelconstraint C over P(T-ART), met C = C1 AC2 AC3 en 


C1(D) = [VEL‚t2 € D [t] (ano) = t,(ano) = t; = t,11. 


C2(D) = (vti,t2 € DIt,(gew) = t,(gew) > t,(pr) = t‚(pr) 1]. 


C3(D) 


(K(itl t ED At(kI).- ra)) < flitl t € D At(KI) = w))1. 


Het tabeltvpe TT-ART wordt gedefinieerd door: 
TT-ART = (DI D € P(T-ART) AC(D)). 


Dit tabeltype bevat zeer veel elementen. n 


Het is theoretisch denkbaar dat een tabeltype TT gelijk is aan de 
machtsverzameling van het bijbehorende kleinste karakteriserende 
tupeltype MT, dus een tabeltype zonder enige tabelconstraints, dus 
zonder een karakteriserend tabelconstraint TTC (formeel: TTC = 
true). Als dan ook nog voor MT geldt dat dit een tupeltype is zonder 
enige tupelconstraints, dan is TT gelijk aan een filetype in Pascal. 
Een Pascal file-type is dus een wel heel speciaal geval van een tabel- 


type. 


Wij beschikken nu over waardenverzamelingen van het tabeltype. 
Wij kunnen nu dan ook variabelen declareren van een tabeltype. 


Voorbeeld 3.13 


Met: 
var A tE 
B1,B2 : TT5; 
BA : TT-ART 
endvar; 


worden variabelen gedeclareerd van het tupeltvpe T (vb. 3.3) en het 
tabeltvpe TT5 (vb. 3.11) respectievelijk TT-ART (vb. 3.12). 


Met het onderstaande programmadeel: 


B1 := < > ; 

A.a := 1; A.b := x; A.C := k; 
B.1 := Bl un <A>; 

A.a := 2; A.b := y; A.c : 
B.1.: 


H 
= 


Bl un <A>; 


wordt bewerkstelligd dat de variabele B1 uiteindelijk twee tupels van 
het type T 'bevat'; dus dan is: 


In dit voorbeeld zijn de volgende svntax-elementen 'ad hoc! inge- 
voerd: 


< : geeft een verzameling weer 
un : symbool voor de operatie ‘vereniging van twee verza- 
melingen'. 
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3.3 ENKELE OPMERKINGEN OVER CONSTRAINTS 


Bij een gegeven objectkarakterisering kunnen talloze tupel- en 
tabelconstraints worden bedacht. Definitie van een constraint heeft 
overigens alleen maar zin, als deze constraint wordt 'bewaakt'. 
Deze bewaking kan geschieden via de toepassingsprogramma's van 
de gebruikers, maar dit zal in het algemeen leiden tot een omslach- 
tige en vooral onbetrouwbare werkwijze. Bewaking van constraints 
hoort dan ook te geschieden door het DBMS (database management 
systeem). Men moet echter niet onderschatten wat dit voor gevol- 
gen heeft voor de omvang en complexiteit (en dus de duurte!) 
van een DBMS-pakket. Het is dan ook niet verwonderlijk dat de 
huidige beschikbare DBMS-pakketten op het gebied van constraints 
nauwelijks iets te bieden hebben. 

Uit het bovenstaande moge wel duidelijk zijn, dat het in het 
algemeen raadzaam is bij de definitie van constraints een wijze 
beperking in acht te nemen. x 


In de voorafgaande paragrafen was sprake van zogeheten statische 
constraints. Dit zijn constraints, die beperkingen opleggen aan 
waarden, die 'op een bepaald moment' mogen optreden. In de loop 
van de tijd kunnen deze waarden echter veranderen. 

Het spreekt vanzelf dat de nieuwe waarden dan ook weer aan de 
statische constraints moeten voldoen. Bij overgang op nieuwe 
waarden kunnen echter nog aparte 'overgangsbeperkingen' ofwel 
zogeheten dynamische constraints gelden. Een bekend voorbeeld 
hiervan is het volgende. 

Het attribuut 'bs' (burgerlijke staat) van een persoon (uit het 
personenregister) kan de waarden ongehuwd (ongehuwd uiteraard 
te verstaan als nooit gehuwd geweest), gehuwd, gescheiden, 
weduwstaat hebben. Nu zullen niet alle overgangen tussen deze 
vier waarden zijn toegestaan, maar alleen die zoals aangegeven met 
"al in onderstaande tabel. 


bs oud bs nieuw | ongehuwd | gehuwd | gescheiden | weduwstaat 
e ef in 
gehuwd nee B 


gescheiden 
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Voor dynamische constraints geldt nog sterker dan voor statische 
constraints, dat de beschikbare DBMS-pakketten daar in het geheel 
niet op ingespeeld zijn. 

In dit boek zullen verder alleen statische constraints worden 
besproken. 


OPGAVEN 


3.1 Geef de constraints C2 en C3 van voorbeeld 3.1 in woorden 
weer. 


3.2 Welke van onderstaande constraints is equivalent met C2 van 
voorbeeld 3.1? 


Ca(t) = [t(ano) < 75 At(gew) > 20] 


Cb(t) = [t(ano) < 75 vt(gew) > 20] 
Ce(t) = [ I(t(ano) < 75) vt(gew) > 20] 
Cd(t) = [t(gew) < 20 > t(ano) > 75] 


3.3 Ga na dat door C1 in voorbeeld 3.1 inderdaad 10 tupels van 
TICE) worden 'uitgeschakeld'. 


3.4 Geef de volgende constraints over MART) (ART van voorbeeld 

2.6c) formeel weer. 

a. Als de prijs > 400 is, mag de voorraad niet groter dan 1000 
zijn. 

b. Bij een prijs < 100 èn een gewicht > 100 mag de kleur niet 
rood zijn. 

c. Bij een prijs < 100 mag het gewicht niet > 100 en de kleur 
niet rood zijn. 

d. Bij een prijs < 100 moet het gewicht < 100 of de kleur niet 
rood zijn. 


3.5 Gegeven onderstaande objectkarakterisering OPN (opname van 
een patient in een ziekenhuis. 


Toelichting 
OPN = {(pnr,‚{1...100000}), patiëntnummer 
(indat, {700101...991231}), datum opname 
(opnr,charstring30), — Opnamereden 
(snr,{ł...100}), nummer opnamespecialist 


(snm,‚charstring25), naam o 
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3.6 


3.7 


3.8 


(pnm ,charstring25), naam patiënt 
(pwpl,charstring25), woonplaats patiënt 
(padr,charstring30), adres patiënt 


(uitdat,{700101..991231}), datum vertrek 
(gbd, {8800101 .9991231}), geboortedatum patiënt 
(anr, {1...100}) } nummer afdeling 


Bedenk enkele tupelconstraints over T(OPN) en geef 
deze formeel en in woorden weer. 

Ga na dat in voorbeeld 3.2 inderdaad geldt: 

Y # ETC EFDA TORC) Fo 

Gegeven het tupeltype T, bepaald door de onderstaande 


objectkarakterisering F en de constraints C1, C2 en C3 
over M(F). 


F = 1(a,11,2,3,4)),(b,15,6,7)),(e,11,k,x,f))) 


C1(t) = [t(a) = 3 > (t(b) = 6 At(ce) = 1] 
C2(t) = [t(e) # f = (t(b) < 5)] 
C3(t) = [t(a) + t(b) < 91 


a. Bepaal de kleinste objectkarakterisering KF van T. 

b. Geef een enumeratieve beschrijving van T. 

c. Is de conjunctie van Cl A C2 A C3 een echte tupelcon- 
straint7 Zo nee, bepaal dan welke attribuutcon- 
straint(s) in deze conjunctie bevat zijn. Welk verband 
bestaat er tussen de antwoorden op vragen a en c? 


Ga na welk van onderstaande verzamelingen Vi tupeltypen 
zijn. Zo ja, bepaal dan de kleinste objectkarakterisering 
Ki en verder IVil en IM(Vi)I. 


a. V1 = 1i(a,5),(b,5)(e,5)),1(a,5),(b,3),(e,2))) 


b. V2 = 1((24,5),(b,5),(e,5)) 

c. V3 = {{(a,5),(b,5),(e,5) F {(a,{5,4}),(b‚3),(c,2) }} 
d. V4 = {{(a,5),(e,5)}, {(a,5),(b‚3),(c,2) }} 

e. V5 = {fl f is een functie A dom(f) € {a,b,c} A rng(f) c 


12,3,5)) 
f. V6 = {fl fis een functie A dom(f) = {a,b,c} arng(f) c 
(2,3,5)) 


3.9 


3.10 


3.11 


3.13 


3.14 


g. V7 = {fl fis een functie A dom(f) = {a,b,c} A rng(f) = 
(2,3,5)) 

h. V8 = (fl fis een functie A dom(f) c {a,b,c} A rng(f) = 
(2,8,5)) 

i. V9 = (fl fis een functie A dom(f) = {a,b,c} rng(f) € 


t is een variabele van het tupeltype T van voorbeeld 3.3, 
a. Ga na, welke van onderstaande beweringen strijdig is met 
de gegeven definitie van T. 


al. t(a) = 4 * t(c) 

a2. t(a) = 4 *t(c) A t(b) = z 
a3. t(a) f 4 x t(c) 

a4. t(b) = y A t(c) = x. 


b. Welke van onderstaande programmadelen zijn toegestaan 
volgens de definitie van T. 
bi. t(a) := 1; t(D) :=z; t(c) sg: 
t(b) := x; t(a) :=t(a) + 1 
b2. t(b) := y; t(e) := 1; t(a) := 3 + t(c); 
t(a) :=t(a) + 1. 


Tabeltype X is als volgt gedefinieerd: 
X = (0,D1,D2) (D1,D2 van voorbeeld 3.6). 


Bepaal het kleinste karakteriserende tupeltype MT van X en 
ook nog een ander karakteriserend tupeltype van X. 


Deze opgave heeft betrekking op voorbeeld 3.7. 

a. Bepaal ITT11,ITT21 en ITT3). 

b. Bepaal het kleinste karakteriserend tupeltype van TT1 en 
van TT3. 

c. Welke van onderstaande verzamelingen A-G zijn tabelt ypen 
en welke van deze tabeltypen zijn gelijk aan TT1, of TT2 
of TT 3? 


A = pU (M(F),X,T); B = (0}U (M(F),X,T); C = (0,Y,T); 
D = (0,(Y),T); E = TT1NY; H = TT3STT1; G-HUTT2. 


Bewijs (enkele regels onder voorbeeld 3.8): KT S MT. 
Geef de constraints van voorbeeld 3. 10 verbaal weer. 


Welke van onderstaande tabelconstraints is equivalent met C2 
van voorbeeld 3.10? | 
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3.15 


3.16 


3.17 


3.18 


Ca(D) (vti,t2 € D(ti(a) f t2(a)] 
Cb(D) = (vti,t2 € D[tl(a) f t2(a) v t1 = t2] 
Ce(D) [Vt1,t2 € D[t1 # t2 > t1(a) # t2(a)). 


Geef de volgende tabelconstraints over P(T-ART) formeel 

weer (T-ART van voorbeeld 3.4): 

a. Het aantal tupels met een gewicht > 20 ën een prijs > 300 
mag niet groter zijn dan 10. 

b. De totale voorraad van rode tafels mag niet minder dan 10 
en niet groter dan 100 zijn. 

c. Van rode tafels mogen hoogstens 10 verschillende prijzen 
voorkomen. 

d. Gelijk gewicht èn gelijke prijs houdt ook in gelijke kleur. 


Ga na dat TT5 van voorbeeld 3.11 inderdaad 54 elementen 

bevat. 

Het tupeltype T-OPN is gedefinieerd door: 

T-OPN = {t| t € (OPN) A C(t)}, waarbij OPN uit opgave 3.5 

en C(t) :=[t(uitdat) > t(indat) A t(opnr) = informaritis > 
t(snm) = brakes]. 

Bedenk tabelconstraints over P(T-OPN) en geef deze formeel 

èn verbaal weer. 


TA is een variabele van het tabeltype TT-ART voor voorbeeld 
3.12. 
a. Ga na, welke van onderstaande beweringen strijdig is met 
de gegeven definitie van TT-ART. 
al. TA = V, waarbij (in tabelvorm weergegeven) 


ano anm pr gew vrd kl 

8 bank 20 25 0 rd 

92 kast 150 150 800 rd 

V = 63 stoel 12 10 10... rd 
103 bank 60 80 15 W 
5 kast 125 15 20 w 


82. TA >V (V als sub al) 


a3. TA c V (V als sub al) 
a4. ITA| = 400 
a5. ITA] = 0. 


b. Welke delen van onderstaand programma zijn toegestaan 
met de gegeven definitie van TT-ART. 


TA 
EA 5 


> 


`" ‘ii 


TA un{{(ano ,90) , (anm ,lamp) ,(pr,30),(gew,7), 
(vrd,82),(kl,w))) 
TA :- TA un(((ano,60),(anm,lamp),(pr,30),(gew,7), 
(vrd,82),(kl,rd))) 
TA := TA un(((ano, 40), (anm,stoel),(pr,40),(gew,7), 
(vrd,120), (kl,rd) }}. 


4 AFHANKELIJKHEDEN; SLEUTEL 


4.1 AFHANKELIJKHEDEN 


In dit hoofdstuk zullen wij ingaan op een belangrijke klasse van 
tabelconstraints, en wel de klasse van afhankelijkheden. 
Voor dit gehele hoofdstuk zullen wij aannemen dat: 


EL een tabeltype is, 
A de verzameling van alle attributen van TT is, 
A,;A9sAq deelverzamelingen van A zijn. 


Ruwweg kunnen wij zeggen dat de attributen(deel)verzameling A 
afhankelijk is van de attributen(deel)verzameling Aj, als de waarden 
van de attributen van Ag ‘vastliggen! door de waarden van de attri- 
buten van Aq. Dit 'vastliggen' gaan wij nu definiċren. 


Definitie 4.1 
(niet-formeel) A, is afhankelijk. van A, onder TT als voor elke tabel 
T van TT geldt: “als een tweetal tupels van T gelijke waarden heeft 
voor Aj: dan zal dit tweetal ook gelijke waarden hebben voor A 


(formeel) Ais afhankelijk van À, onder TT b 
VTETT [ Vt1,t2eT [t A; wt TA, > t‚[A, = t,1A,11. o 
Notatie: A, > A. 
1 TT 2 


Als duidelijk is (uit de context) onder welk tabeltype een afhanke- 
lijkheid geldt, dan wordt de aanduiding van het desbetreffende 
tabeltype meestal weggelaten, en dus ook in de notatie A; > Aj: 


Uit de definitie volgt onmiddellijk: 

Als A, afhankelijk is van A,, dan geldt voor elke tabel T van TT, 
dat dë paren (t ES IA) van alle tupels t van T een functie vormen 
èn omgekeerd. 


Meer formeel: 


A, > A, @ VTETT [{(t[A ,t[A,) It € T) is een functie]. 


Hiermee moge duidelijk zijn, waarom in de database-literatuur dik- 
wijls het begrip afhankelijkheid wordt aangegeven met 'functionele 
afhankelijkheid! (Engels: functional dependency). 


Voorbeeld 4.1 


Voor dit voorbeeld roepen wij in herinnering (de constructie van) 
tabeltype TT-ART (voorbeelden 2.6c, 3.1, 3.4, 3.12). 


— objectkarakterisering ART 
ART = ((ano,11...100)),(anm,charstring 20), (pr, {10...500}), 
(gew, {1...300}),(vrd, (0... 10000 }) , (kl, {rd ‚w ‚bl }) }. 


— tupelconstraints C2 en C3 over MART) 
C2(t) :- (t(ano) < 75 > t(gew) > 20) 
C3(t) := (t(pr) xt(vrd) < 100000) 


— tupeltvpe T-ART 
T-ART š {tit EMART) A (C2 A C3)(t)). 


— tabelconstraints C1, C2 en C3 over P(T-ART) 
CKD) := [Vt1,t2eD [t (ano) = t,(ano) = ti = t,11 


C2(D) : Ivti,t2eD(t, (gew) = t,(gew) > t‚(pr) = t,(pr))) 
CD) := [#((tI t€ D (OD = rd)) s#((t] t€ D A t)k)) = WJ]. 


- tabeltype TT-ART 
IT-ART = {DID € P(T-ART) A (C1 a C2 A C3)(D)}. 


Onder TT-ART is blijkbaar (pr) afhankelijk van (gew). Immers 
tabelconstraint C2 is geldig voor elk element van TT-ART, en deze 
tabelconstraint C2 is equivalent met: 


Vt1,t2eD [(t‚ [ {gew} = t| {gew } = t [{pr} = t| {pr }]. 


Verder volgt ook nog uit de tabelconstraint-C1 de afhankelijkheid 
{ano} > ATT-ART, waarbij ATT-ART de verzameling is van alle 
attributen van TT-ART. o 


Als A, > Ag, dan noemen wij het geordende paar (A al een 
afhankelijkheid (onder TT). De eerste coördinaat van eên afhanke- 
lijkheid wordt ook wel het linkerlid ofwel de determinant van de 
afhankelijkheid genoemd. De tweede coördinaat heet ook wel het 
rechterlid ofwel de gedetermineerde van de afhankelijkheid. 


In de literatuur komt men dikwijls zinsneden tegen zoals 'time- 
varying dependencies'. Dit time-varying aspect van een afhankelijk- 
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heid heeft nu formeel gestalte gekregen in dat deel van definitie 4.1 
waar sprake is van elke tabel van TT of meer formeel VT € TT. 


Belangrijk is het onderscheid tussen zogeheten triviale en niet- 
triviale afhankelijkheden. 


Definitie 4.2 
(niet-formeel) A, is triviaal afhankelijk van A; als A een deelver- 
zameling is van A4. 


(formeel) A is triviaal afhankelijk van A As A, o 


2 1 


1 


Het is eenvoudig in te zien dat uit A, c A, volgt A; > Aj. De naam 
triviale afhankelijkheid is dus terech gekdzen. Het triviale is gele- 
gen in het feit, dat deze afhankelijkheid geldt, ongeacht de waarden, 
die de attributen kunnen aannemen. Een verzameling van attributen 
is dus altijd triviaal afhankelijk van elke 'omvattende' attributenver- 
zameling. 


'Afhankelijk van' is een transitieve relatie (tussen de deelverzamelin- 
gen van de attributenverzameling A), zoals blijkt uit: 


Stelling 4.1 (Transitiviteitsstelling) 
Als Aj. A.A. c A en Au > A, en A, + Ag dan geldt: A, Ké Ag. 
Bewijs: Uit A; > A volgt : 

(VTE TE [ Vt1;42 ET [t [A = to [A] > t.[A, = t,1A,11. 


Uit A, — Aq volgt : 


(2) VT EETL WIED € T IER = t,1A, => t. [As = ta [Aa] j; 


Uit (1) en (2) volgt: 
(3) VT ETT[ vti EN [t [A] = ta [A] = t. [Ag = to [Aa] l- 


Dus: A, — Ag: n 


'Afhankelijk van' is ook een reflexieve relatie (tussen de deelverza- 
melingen van de attributenverzameling A. Er geldt namelijk voor elke 
A; c A: A; + A; (triviale afhankelijkheid). 

'Afhankelijk van' is geen equivalente relatie (tussen de deelverzame- 
lingen van de attributenverzameling A). Met andere woorden: uit 

A, > A, volgt niet A, > Ay. 

Gċidt echter voor A, en A, zowel A, > A, als A, ġġ Aj dan zeggen 


wij dat A, equivalent is met A, Notatie: A, A. 
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Nu volgen enkele stellingen voor het afleiden van afhankelijkheden 
uit gegeven afhankelijkheden. Overigens was stelling 4.1 al zo'n 
stelling. 


Stelling 4.2 (Rechter verenigingsstelling) 


Als A; > Ag èn Au + Ag dan geldt Au + A, U Ag: 


Bewijs: Uit A; > A volgt : 
(1) VT ETT(VtI,t2 € Tit [A] = t,[A, > t, [A, = t,1A,11. 


Uit A; > Ag volgt: 


(2) VTETT[vt1,t2 € Tit [A] = t,TA, > t,[A, = t,1A,11. 


Uit (1) en (2) volgt: 
(3): VIE TP Vt1;t2 € Tit [A = təl A] = t,IA,UA, = t,[A,UA,] li 


Dus: A, > A9 U Ag: im) 


Stelling 4.3 (Linker uitbreidingsstelling) 


Als A; > A, en Ag PA; dan geldt Ag al WI 


Bewijs: Uit Ag DAL volgt (triviale afhankelijkheid) 
(1) A, > A, 
Uit (1) en A; > A, volgt (met stelling 4.1): A, > Aan 
Stelling 4.4 (Rechter inkrimpingsstellina) 


Als A, + Ag en Ag € A, dan geldt Au + Ag. 


Bewijs: Wordt overgelaten aan de lezer (zie opgave 4.1). o 


Stelling 4.5 (Verenigingsstelling) 


Als A, + A, en Ag > Ag dan geldt A; U Ag > A, U Ag: 


Bewijs: Uit A; > A, volgt (met stelling 4.3): 
(1) A, U Ag > Aj. 


Uit Ag > A, evenzo: 


(2) A; U Ag > A 
Uit (1) en (2) met stelling 4.2: A, U As > Ay U A: D 
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Als A9 afhankelijk is van Ai, dan hoeft dat nog niet te betekenen, 
dat ad geen echte deelverzameling Ay, van Aj is zó dat Ajj > Ag. Is 
er echter niet zo'n deelverzameling, den segan wij dat Aa van de 
volledige A; afhankelijk is. Een en ander wordt nu vastgelegd in: 


Definitie 4. 3 

(niet-formeel) Ag is afhankelijk van de volledige Aj als Ag afhanke- 

lijk is van Ai en Ag niet afhankelijk is van een echte deelverzameling 

van A. 

(formeel) A, 
B A, + A, èn VDCA,[D # A, > ](D All, a 


is afhankelijk van de volledige AR 


Notatie: Au H As: 


Een linkeruitbreidingsstelling kan uiteraard niet gelden voor volledi- 
ge afhankelijkheid, maar ook is er geen rechter inkrimpingsstelling 
voor volledige afhankelijkheid. 


Dus uit A, $ A, volgt niet: VatA, LA, + (ad). 


Het kan zelfs voorkomen dat, niettegenstaande A; 5 A, geldt, voor 
geen enkele a € A, geldt A, X {a}. Een tegenvoorbeeld is het volgen- 
de: 

Voorbeeld 4. 2 


Tabeltype TT6 bevat uitsluitend de hieronder weergegeven elementen 
Tien T2. (al,a2,a3,a4,a5}is de attributenverzameling ATT6 van 
TT6. 


al ak AS 88 mW RM 5: VE, 
1 4 7 p 5 2 6 7 p t 
1 6 7 p s 2 5 7 p s 

Ti y 1 4 9 p S T2 = 1 4 7 q t 
2 5 9 q t 1 4 9 q t 
3 5 9 p t 2 5 9 p s 
3 4 7 p S 


De lezer ga na dat geldt: 


(al,a2) $ (ad. ap) 
{al} > {a4} 
{a2} > {a5} D 
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Ten aanzien van volledige afhankelijkheid geldt wel de volgende stel- 
ling: 


Stelling 4.6 
tari. Aq5A5sAg34 CA fa (2) A; > A, en (3) Aoi f A, en (4) 
A; Aan dan geldt: A; > Aj: 
Bewijs. Stel (5) D c A, en (6) D > Ag 
Uit (6) en (3) volgt: 
(7) D> Ao: 
Uit (7), (4) en (5) volgt: 
(8) D= SI i 
ħ ja Vi | 
Dus (D c A, ën D > A,) > D = Ay. Dus A, > Aa o 


Een direct gevolg van stelling 4.6 is dat als de volledige afhankelijk- 
heid (A,,A9j) wordt 'uitgebreid' tot de afhankelijkheid (An, Aa), 
waarbij As, € Ag, dan is de afhankelijkheid (A,,A9) ook weer volle- 
dig. Dus bij 'uitbreiding' van het rechterlid blijft volledige afhanke- 
lijkheid behouden. 


4.2 SLEUTEL 


Het bijzondere van de afhankelijkheid ({ano},A) in voorbeeld 4.1 is, 
dat de verzameling van alle attributen afhankelijk is van {ano}. 


Een attributenverzameling, waarvan de gehele attributenverzameling 
afhankelijk is, noemen wij een uniek identificerende attributenverza- 
meling van TT. Als {ano} uniek identificerend is, dan zullen ook 
alle D > {ano} uniek identificerend zijn. 
We zullen nu het begrip sleutel invoeren als een bijzondere, uniek 
identificerende attributenverzameling. 


Definitie 4. 4 

(niet-formeel) Aj is sleutel van TT als de gehele attributenverzame- 
ling A afhankelijk is van de volledige A4. 

(formeel) D 


: L ħ f 
A, is sleutel van TT = A; T A. o 


Opmerking 
In de literatuur bestaat geen eenduidige opvatting over het begrip 
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sleutel (key). Velen definiëren sleutel (op min of meer duidelijke 
manier) als in definitie 4.4. Er zijn echter ook auteurs die sleutel 
definiëren in de zin van alleen uniek identificerend. 


Uiteraard kan een tabeltype meer dan één sleutel hebben. We spre- 
ken daarom van de sleutelverzameling van een tabeltype. Hierbij is 
het zinloos onderscheid te maken tussen zogeheten primaire en 
secundaire sleutels, zoals door diverse auteurs wordt gedaan. 


Voorbeeld 4.3 


Gegeven is tabeltype TT-ORDER met K-ORDER als kleinste object- 
karakterisering en de afhankelijkheden f1 tot en met f7. 


K-ORDER = Toelichting 

((onr,11...100000)), ordernummer 
(dat, {700101...991231}), dat um 
(Inr,11.1.100)), leveranciersnummer 
(arc, (1...100)), artikelcode 
(hoev,11...100000)), hoeveelheid 
(Inm ,charstring 25), leveranciersnaam 
(anm,charstring 20), artikelnaam 
(ladr,charstring 30), leveranciersadres 
(lwpl,‚charstring 20), leverancierswoonplaats 
(bestadr,charstring 30), besteladres 
(pr,110...5000)) prijs per stuk. 

fi : {onr} + A (A = dom(K-ORDER)) 


f2 : (Inr,are,dat) $ A 
f3 : {Inr} — {lnm} 

fa : {arc} +> {anm} 

f5 : {Inr} > {ladr,lwpl} 
f6 : (Inr,arc) $ (pr) 
f7 : {arc} + {bestadr }. 


Uit fl en f2 volgt dat {onr} en (Inr,arc,dat } sleutels zijn. Uit fl t/m 

f4 volgt dat de sleutelverzameling s is: 

s = {{onr}, (np, are, dat }, {lnm ,arc,dat }, {Inr ‚anm ‚dat }, {(lnm,anm ‚dat }}. 
D 


Het is eenvoudig in te zien, dat sleutels van eenzelfde tabeltype 
onderling equivalent zijn. Omdat elke sleutel 'minimaal' is, bevat een 
sleutel geen echte deelverzameling die equivalent is met deze sleutel. 
Wel kan het voorkomen dat echte deelverzamelingen van twee ver- 
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schillende sleutels equivalent zijn, zoals {Inr} en {lnm} in voorbeeld 
4.3. Ook deze equivalentie zal echter niet meer kunnen voorkomen, 
als sprake is van zogeheten genormaliseerde tabeltypen (onderwerp 
van het volgende hoofdstuk). 


OPGAVEN 


4.1 Geef het bewijs van stelling 4.4 


4.2 Bewijs: Als A,A, c A, dan geldt 


(A, + Ag) e (Ya€A LA, > Lal). 


4.3 (opgave bij voorbeeld 4.2) 
a. Ga na dat de genoemde afhankelijkheden inderdaad gelden. 
b. Bepaal de sleutelverzameling van TT6. 
c. Los X op uit: 
Bi. K> tall; EC + (a$); 63. jet. et Y X; 


c4: (a2,843) $ X. 
d. Bepaal alle deelverzamelingen van ATT6 die equivalent zijn 
met (al,a2). 


4.4 Bewijs dat A, 5 A, equivalent is met VDEA, [ (D>A,) 9 (D=A‚)1. 


4.5 (opgave bij voorbeeld 4.3) 
a. Welke van onderstaande beweringen is waar? 
al. {onr} > {arc‚hoev}; a2. {onr‚lnr } > {arc,hoev }; 
a3. ilnr,arc) > {Inm‚anm}; a4. {lnr‚arc} > (Inm,amn,pr); 


a5. (onr,inr) $ (ladr,lwpl); a7. {anm,lnr} $ (hoev). 
b. Geef commentaar op de volgende beweringen. 

bi. Per order kunnen meerdere leveranciers optreden. 

b2. EIk artikel heeft een vaste prijs. 

b3. Per order wordt het besteladres vastgesteld. 


5 NORMALISATIE 


5.1 GENORMALISEERD TABELTYPE 


Tot nu toe hebben wij dikwijls gesproken over attributen van een 
object (karakterisering), maar eigenlijk niet 'bekeken' of elk van de 
genoemde attributen wel echt bij dat object 'thuishoort'. Als wij bij- 
voorbeeld de attributen van de objectkarakterisering K-ORDER van 
voorbeeld 4.3 onder de loep nemen, dan ligt het voor de hand dat 
attributen als 'onr', 'dat', 'hoev' er echt in thuishoren, terwijl dit 
niet zo duidelijk is voor attributen als 'Inm', 'ladr', 'Iwpl', 'anm'. Of 
een bepaald attribuut in een objectkarakterisering thuishoort, moet 
uiteraard geen nietes-welles spelletje worden. Wij moeten formeel- 
duidelijke criteria aanleggen, waarmee te toetsen valt of een attribuut 
wel of niet tot een karakterisering behoort. Deze criteria dienen te 
zelfder tijd semantisch duidelijk te zijn, dat wil zeggen: ze dienen te 
appeleren aan een intuïtieve 'opdeling' van de attributen over de 
objectkarakteriseringen. 

Met het begrip afhankelijkheid en meer in het bijzonder het begrip 
sleutel (in het vorige hoofdstuk) hebben wij een goede basis gecre- 
eerd voor bedoelde criteria. Met behulp van deze begrippen zullen 
wij nu het begrip 'genormaliseerd tabeltype' vastleggen. 


Definitie 5.1 

Stel A4 en Ag zijn deelverzamelingen van de attributenverzameling 
van het tabeltype TT ċn SL is de sleutelverzameling van TT. 
(niet-formeel) TT is een genormaliseerd tabeltype als voor elke niet- 
triviale afhankelijkheid A, + A, geldt dat A, een sleutel bevat. 


(formeel) 1 D i 
TT is een genormaliseerd tabeltype = voor elke niet-triviale afhanke- 
lijkheid A, p+ A, geldt: [3SESL[s c A.J). o 


Voorbeeld 5.1 


Tabeltype TT-ORDER van voorbeeld 4.3 is niet genormaliseerd. Er 
geldt namelijk {Inr } > {lnm} en dit is een niet-triviale afhankelijk- 
heid, waarvan het linkerlid geen sleutel bevat. Overigens is f3 niet 


63 


de enige afhankelijkheid, waarvoor het bovenstaande geldt. 

Om, met behoud van ‘informatiewaarde! tot een genormaliseerde 
opzet te komen, zal het nodig zijn om met meer dan één tabeltype te 
werken. In dit geval kunnen daarvoor de vier onderstaande tabel- 
typen dienen: | 


1. Tabeltype TT-ORDER-N met K-ORDER-N als kleinste objectkarak- 
terisering en de afhankelijkheden f1 en f2: 
K-ORDER-N = 
((onr,11...100000)), 
(dat,1700101...991231)), 
(Inr,11...100)), 
(are, (1...100)), 
(hoev,11...100000))). 


fl: {onr} > AN 
f2: Dn are dat) V AN 


waarbij AN de attributenverzameling van TT-ORDER-N is. 
Uit het voorgaande volgt dat 


S-ORDER-N = {{onr}, (Inr,are,dat }}, 
waarbij S-ORDER-N de sleutelverzameling van TT-ORDER-N is. 


2. Tabeltype TT-LEV-N met K-LEV-N als kleinste objectkarakterise- 
ring en de afhankelijkheden f3 en f5: 
K-LEV-N = 
{(Inr, {1...100}), 
(Inm ,,charstring 25), 
(ladr,charstring 30), 
(Iwpl,charstring 20) }. 


f3: {Inr} +> {Inm} 
f5: {Inr} > {ladr ,lwpl}. 


Uit het voorgaande volgt dat S-LEV-N = ((Inr ), {Inm }}, waarbij 
S-LEV-N de sleutelverzameling van TT-LEV-N is. 


3. Tabeltype TT-ART-N met K-ART-N als kleinste objectkarakterise- 
ring en de afhankelijkheden f4 en f7: 
K-ART-N = 
((arc, (1..:1001); 
(anm,charstring 20), 
(bestadr,charstring 30) }. 


fa: {arc} +> {anm} 
D: {arc} + (bestadr). 
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Uit het voorgaande volgt dat S-ART-N = {{arc}, {anm }}, waarbij 
S-ART-N de sleutelverzameling van TT-ART-N is. 


4. Tabeltvpe TT-ASS-N (ASSortiment) met K-ASS-N als kleinste 
objectkarakterisering en de afhankelijkheid f6: 


K-ASS-N = | 
((Inr,(1...100)), 
(arc,(1...100)), 
(pr,110...5000))). 


f6: (Inr,arc) > {pr}. 


Uit het voorgaande volgt dat S-ASS-N = ((Inr,arc)), waarbij 
S-ASS-N de sleutelverzameling is van TT-ASS-N. o 


In het voorgaande voorbeeld is sprake van genormaliseerde opzet, 
met behoud van informatiewaarde. Voor dit behoud van informatie- 
waarde is in ieder geval nodig dat de attributen en de afhankelijkhe- 
den van het ongenormaliseerde tabeltype, waarvan we uitgaan (zoals 
in het voorbeeld TT-ORDER), allemaal moeten zijn 'terug te vinden' 
in de genormaliseerde opzet. Met name geldt dit voor de attributen 
en afhankelijkheden, die uit het ongenormaliseerde tabeltype moeten 
'verdwijnen', om dit tabeltype zelf te 'normaliseren'. (In het voor- 
beeld zijn de 'te verdwijnen' attributen: lnm, ladr, lwpl, anm, pr, 
bestadr. Met deze attributen verdwijnen dan ook de afhankelijkheden 
f3 tot en met f7.) Deze attributen zullen dan een plaats moeten vin- 
den in bestaande tabeltypen of in nieuw te definiëren tabeltypen. 

Om te bereiken dat genoemde attributen en afhankelijkheden zodanig 
worden ondergebracht dat alleen genormaliseerde tabeltypen ont= 
staan, zal het nodig zijn dat elke afhankelijkheid f zodanig wordt 
‘ondergebracht! in een tabeltype TT dat het linkerlid van f een sleu- 
tel bevat van TT. 

Behoud van informatiewaarde betekent ook dat bij elke tabel 
T-ORDER-N van TT-ORDER-N een tabel van respectievelijk TT- 
LEV-N, TT-ART-N, TT-ASS-N beschikbaar dient te zijn, met de bij 
elk ordertupel van T-ORDER-N behorende informatie over respectie- 
velijk leverancier, artikel, assortiment. 

Dit verband tussen tupels van tabellen van verschillende Label ` 
typen dient nog formeel vastgelegd te worden. Daartoe kunnen wij 
pas overgaan na invoering (in het volgende hoofdstuk) van het zoge- 
heten databasetype. Voorlopig spreken wij af, dat genoemde verban- 
den vastliggen door gelijke attribuutnamen: 'Inr' in K-ORDER-N en 
in K-LEV-N, 'arc' in K-ORDER-N en in K-ART-N, 'Inr' en 'arc' in 
K-ORDER-N en in K-ASS-N. 


Toen in 1970 door Codd het normalisatiebegrip werd ingevoerd, 
maakte hij onderscheid tussen eerste, tweede en derde normaalvorm. 
INF, 2NF, 3NF zijn hiervoor de gebruikelijke afkortingen (NF = 
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Normal Form). Daarna zijn er nog (door Fagin en anderen) 'hogere' 
normaalvormen ontwikkeld, zoals 4NF en 5NF. 

Als argument voor normalisatie werd en wordt nog steeds aange- 
voerd, dat daarmee redundantie in opslag van gegevens zou worden 
vermeden. 

Op de (verschillende) normaalvormen zullen wij in paragraaf 5.2 
ten dele ingaan en de argumentatie voor normalisatie zal worden 
besproken in paragraaf 5.3. 


5.2 NORMAALVORMEN 


We zullen in feite alleen de eerste normaalvorm bespreken en ons 
voor de overige normaalvormen tot enkele opmerkingen beperken. 

De eerste normaalvorm is de meest merkwaardige en meest ondui- 
delijk gedefinieerde normaalvorm, die overigens tot op heden nog 
steeds als zodanig wordt gebruikt door de meeste auteurs. Een tabel- 
type heet dan in eerste normaalvorm, als alle attribuutwaarden 'ato- 
mair' zijn. In plaats van 'atomair' wordt ook gesproken van 'niet 
verder opsplitsbaar'. Men drukt dit ook wel uit door te zeggen, dat 
er geen zogeheten 'repeating groups' in een object-occurrence mogen 
voorkomen, zoals bijvoorbeeld meerdere waarden voor het attribuut 
'anm' in een tupel van het tupeltype T-ART van voorbeeld 3.4. In 
onze formele opzet is deze 'meerwaardigheid' van een attribuut in 
een tupel per definitie uitgesloten. Door de gekozen definitie van 
tupeltype wordt in een tupel aan elk attribuut precies één waarde 
toegevoegd uit de verzameling van voor dat attribuut mogelijke waar- 
den. Dit wil niet zeggen, dat in deze verzameling van attribuutwaar- 
den geen waarden zouden kunnen voorkomen, die de 'schijn' hebben 
van 'meerwaardigheid'. Een voorbeeld moge dit laatste verduidelijken. 

Voor het attribuut 'anm' (artikelnaam) zou de volgende waarden- 
verzameling W1 = {lepel,vork ‚mes } denkbaar zijn, maar ook W2 = 
{lepel ,vork ‚mes ‚lepel-vork, vork-mes, lepel-vork-mes ). W2 bestaat 
niet uit 3, maar uit 6 elementen, en is dus niet gelijk aan WI. Zowel 
W1 als W2 kunnen worden gekozen als waardenverzameling van attri- 
buut 'anm'. Als echter W1 gekozen is, kunnen geen waarden als 
'lepel-vork' of 'vork-mes' of 'lepel-vork-mes' voor het attribuut anm 
in een tupel optreden. Of een bepaalde waarde wel of niet tot een 
waardenverzameling behoort, is geheel ter beoordeling van de 
gebruiker, dus van degene die verantwoordelijk is voor de betekenis 
van de in de database opgeslagen gegevens. 

De reden om, in bovenstaand voorbeeld, W1 te kiezen als waar- 
denverzameling van attribuut anm zou kunnen zijn: lepels, vorken 
en messen worden uitsluitend 'los van elkaar' verkocht en ingekocht. 
Voor W2 zou gekozen kunnen worden.als, naast deze 'losse ver- en 
inkoop' ook transacties plaatsvinden waarbij de combinaties lepel- 
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vork, lepel-vork-mes en vork-mes kunnen voorkomen, bijvoorbeeld 
door aanbieding van deze combinaties in één verpakking. 

Over INF kunnen wij dus samenvattend zeggen: elk tabeltype is 
per definitie in INF, zonder daarbij te hoeven terugvallen op vage 
termen als 'atomair', ‘ondeelbaar! e.d. 


Nu enkele woorden over tweede en derde normaalvorm. Vertaald in 
de formele opzet van dit boek kan worden gesteld dat een tabeltype 
in tweede normaalvorm (2NF) is, als elk attribuut afhankelijk is van 
elke volledige sleutel, waarvan het geen deel uitmaakt. En een tabel- 
type is in derde normaalvorm (3NF) als het in 2NF is ċn er geen 
afhankelijkheid bestaat, waarvan het linkerlid niet tot een sleutel 
behoort. In voorbeeld 4.3 is TT-ORDER niet in 2NF vanwege f3 tot 
en met f7. 


Op 'hogere normaalvormen' wordt in dit boek helemaal niet ingegaan. 
Voor uitgebreide informatie over normaalvormen zijn verwezen naar 
o.a. DATE. 


Gezien de 'historische betekenis' van normaalvormen is er in deze 
paragraaf enige aandacht aan gewijd, zonder van deze normaalvor- 
men als zodanig overigens gebruik te maken. Hiermee wil beslist niet 
gezegd zijn, dat het normalisatiebegrip als zodanig niet erg zinvol 
zou zijn (zie ook volgende paragraaf). 


5.3 ARGUMENTEN VOOR NORMALISATIE 


Als argument voor normalisatie werd en wordt nog dikwijls aange- 
voerd, dat daarmee redundantie in opslag van gegevens zou worden 
vermeden. Redundante opslag van gegevens kan echter zeer zinvol 
zijn, afhankelijk van de wijze waarop men van de opgeslagen gege- 
vens gebruik wil maken. Redundante opslag kan zelfs noodzakelijk 
zijn in verband met eisen betreffende responstijden. Ter illustratie 
de volgende beschouwing bij voorbeeld 5.1 (van orders, leveran- 
ciers, artikelen en assortimenten). 
Stel dat een vraag naar gegevens over een order 
— snel moet kunnen worden beantwoord, èn 
— daarbij ook meestal de naam van de leverancier en de prijs nodig 
zijn. 
Bij zulke responseisen zal het nuttig, zo niet noodzakelijk zijn bij 
elk ordertupel leveranciersnaam en prijs op te slaan. Dit kan uiter- 
aard tot behoorlijk redundante opslag van deze twee attributen lei- 
den. Maar dan spreken wij ook niet meer over de logische structuur, 
maar over de opslagstructuur. Bij figuur 1. in hoofdstuk 1 werd 
reeds benadrukt, dat door eisen betreffende toegang tot de gegevens 
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de logische structuur niet 'onverlet' overgenomen kan worden in de 
opslagstructuur. Er zij nogmaals op gewezen dat de logische struc- 
tuur louter afhankelijk is van de betekenis van de gegevens. Norma- 
lisatie heeft alleen betrekking op de betekenis van de gegevens. Als 
gevolg van normalisatie mag wel worden verwacht dan zinloze redun- 
dantie zal worden vermeden. 


5.4 VERBANDEN TUSSEN OBJECT OCCURRENCES 


Tussen object-occurrences van verschillende objeeten en dus tussen 
tupels van tabellen van verschillende tabeltypen kunnen verschillen- 
de verbanden worden onderscheiden. 


Tussen tupels van tabellen T1 en T2 van twee verschillende tabel- 
typen TTI en TT2 onderscheidt men de volgende verbanden: 


één op één ESCH 
één op veel KE ñ) 
veel op veel (n : m) 


met de volgende betekenis: 


T4 T2 betekenis 

t SE i bij elk tupel van T1 hoort precies één tupel van T2 
èn omgekeerd 

200 bij elk tupel van T1 horen n (n 20) tupels van T2 
en bij elk tupel van T2 hoort precies één tupel van 
Ti 

Ed ` bij elk tupel van T1 horen m (m 20) tupels van T2 


en bij elk tupel van T2 horen n (n 20) tupels van T1. 


Voor de voorbeelden van deze paragraaf wordt uitgegaan van de vol- 
gende vier genormaliseerde tabeltvpen: 


tabeltype voor representatie van sleutel 


TT-AF AFdelingen {afnr } 
TT-WN WerkNemer {wnr } 
TT-PR PRoject {pnr } 
TT-AT ArTikel {atnr } 


Voorbeeld 5.2 


a. 1:1 verband 
Elke werknemer hoort bij precies één afdeling èn elke afdeling 
heeft precies één werknemer in dienst. 
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Om dit (gekunstelde) 1:1-verband te representeren moet afnr een 
attribuut zijn van TT-WN èn wnr een attribuut van TT-AF. 
Overigens kunnen in dit geval de tabeltypen TT-AF en TT-WN 
door één genormaliseerd tabeltype worden vervangen. Normalisa- 
tie alleen leidt niet dwingend tot zulke samenvoeging. 


b. 1:n verband 
Elke werknemer hoort bij precies ċċn afdeling ċn een afdeling kan 
meerdere werknemers in dienst hebben. 
Om dit (meer reċle) 1:n-verband te representeren met genormali- 
seerde tabeltvpen zal afnr een attribuut moeten zijn van TT-WN. 


c. n:m verband 
Elk artikel kan geleverd worden door meerdere afdelingen èn elke 
afdeling kan meerdere artikelen leveren. 
Om dit n:m-verband te representeren met genormaliseerde tabel- 
typen zal het nodig zijn om naast de reeds genoemde tabeltypen 
nog een nieuw tabeltype (TT-AFAT) ter beschikking te hebben, 
waartoe onder meer de attributen afnr en atnr behoren. o 


Voor verbanden tussen tupels van tabellen T1, T2 en T3 van drie 
verschillende tabeltypen TT1, TT2 en TT3 is nu verder alleen nog 
van belang het zogeheten 'veel op veel op veel'-verband (ni:n2:n3). 
De betekenis hiervan is: bij elk tupel van T1 horen meerdere tupels 
van T2 en T3 èn bij elk tupel van T2 horen meerdere tupels van T1 
en T3 èn bij elk tupel van T3 horen meerdere tupels van T1 en T2. 


Voorbeeld 5.3 


nl:n2:n3 verband 
Elke afdeling kan aan verschillende projecten verschillende artikelen 
leveren èn aan elk project kunnen door verschillende afdelingen ver- 
schillende artikelen worden geleverd èn elk artikel kan door ver- 
schillende afdelingen aan verschillende projecten worden geleverd.. 
Kortweg: om een individuele levering als zodanig te herkennen moe- 
ten (minstens) bekend zijn: afdeling, project en artikel. 

Om dit verband te representeren met genormaliseerde tabeltypen 
zal het nodig zijn een nieuw tabeltype ter beschikking te hebben, 
waartoe onder meer de attributen afnr, pnr en atnr behoren. o 


OPGAVEN 


5.1 (bij voorbeelden 4.3 en 5.1) 
Uitgegaan wordt van K-ORDER als in voorbeeld 4.3. Verder 
worden vier los van elkaar staande specificaties gegeven als 
hieronder sub a tot en met d. 


9.2 


LOT ° 
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. Verder gelden f1 èn f3 tot en met f7. 

. Verder gelden f1 tot en met f7 èn {arc} > (hoev). 

Verder gelden f1 tot en met f5 èn f7 en {Inr} > {pr}. 

e Verder gelden f1 tot en met f5 èn f7 èn de tupelconstraint C1 


en de tabelconstraint C2 met: 


Clt) := [t(arc) = A16 > t(pr) = 83] èn 
C2(D):= [#({t(Inr) l t € D)) < 10]. 


Geef, voor elk van de gevallen a, b, c, d apart, hoe de gege- 
vensstructuur kan worden weergegeven met genormaliseerde 


tabeltvpen. 


Gegeven zijn onderstaande tabeltvpen TT-PAT (patiënten), 
TT-OPN (opnamen) en TT-SP (specialisten). TT-PAT met 
K-PAT als kleinste object-karakterisering en de afhankelijkheid 


fl. 

K-PAT = 

((pnr,11...1000000)), 
(pnm ,charstring 25), 
(padr,charstring 20), 
(pwpl,charstring 20), 
(gbd integer) 
(gesl, {m ‚v }) } 


fl: {pnr} > dom(K-PAT) 


Toelichting 


nummer 

naam 

adres 
woonplaats 
geboortedatum 
geslacht 


TT-OPN met K-OPN als kleinste object-karakterisering en de 


afhankelijkheden f2-f6. 
K-OPN = 


{(pnr, {1...1000000}), 
(pnm,,charstring 25), 
(gbd integer) 
(indat, {700101...991231}), 


(uitdat, (700101...991231)), 


(opnr,charstring 25), 
(spnr,{1...2000}), 
(snm,‚charstring 25), 
(anr, {1...200}), 
(enr,‚{1...1000}), 


Toelichting 


patiċntnummer 

patiċntnaam 

geboortedatum 
opnamedatum 

ontslagdatum 

reden opname 

nummer specialist 

naam specialist 
afdelingsnummer 

nummer van verpleegruimte 


f2: ipnr,indat) — dom(K-OPN). 


f3: {pnr }<>'{pnm} | 
fa: {pnm} > {gbd} 

f5: {spnr} > {snm} 

f6: {rnr} + {anr} 
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TT-SP met K-SP als kleinste object-karakterisering en de af- 
hankelijkheid f7. 


K-SP = Toelichting 
((spnr,11...2000)), nummer 
(snm ,charstring 25), naam 
(sadr,charstring 20), adres 
(swpl,charstring 20), woonplaats 
(anr, {1...200}), afdelingsnummer 
(telefnr ,integer) } telefoonnummer 


f7: {spnr} > dom(K-SP) 


Geef met behulp van genormaliseerde tabeltypen de informatie 
van bovenstaande tabeltypen weer. 


5.3 (uitgangspunt bij deze opgave zijn de vier tabeltypen, 

genoemd aan het begin van paragraaf 5.4) 

Wat is nodig om elk van de onderstaande specificaties te repre- 

senteren? 

a. Elk project beschikt over meerdere werknemers en elke 
werknemer is aan precies één project toegevoegd. 

b. Elke afdeling kan verschillende artikelen aan verschillende 
projecten leveren èn elk artikel wordt aan elk project door 
precies één leverancier geleverd. 


5.4 Welke verbanden (in de zin van paragraaf 5.4) liggen opgeslo- 
ten in voorbeeld 5.1? 


6 DATABASETVPE; 
SUBSET REOUIREMENTS 


6.1 DATABASETYPE 


In het vorige hoofdstuk werd al enigszins gewag gemaakt van moge- 
lijke verbanden tussen tupels van tabellen van verschillende tabel- 
typen (bijvoorbeeld tussen tupels van tabellen van de tabelt ypen 
TT-ORDER-N, TT-LEV-N, TT-ART-N en TT-ASS-N van voorbeeld 
5.1). In 'bestands'- en 'recordtermen' gaat het om mogelijke verban- 
den tussen records van verschillende bestanden. Wij zijn dus geïn- 
teresseerd, niet in één bestand, maar in een verzameling van 
bestanden. Zo'n verzameling van bestanden wordt 'losweg' aangeduid 
met de term 'database'. In tegenstelling tot de begrippen 'bestand 
(file)' en record heeft het begrip 'database' nog geen plaats gekre- 
gen in programmeertalen als Pascal. Wel komt het voor in de zogehe- 
ten DDL (Data Description Language) van verschillende database 
management systemen. In het algemeen kan men zeggen dat het in 
deze systemen gebruikte begrip database een bijzonder geval is van 
het hier te definiëren begrip databaset ype. 


In deze definitie zullen wij gebruik maken van het begrip 'verwante' 
functies. 

Twee functies zijn verwant, als zij niet leeg zijn en hetzelfde 
domein hebben. Als V een verzameling verwante functies is, noemen ` 
wij het gemeenschappelijke domein van deze functies het domein van 
V (notatie: dom(V)). 

Nu volgt de definitie van databasetype. 


Definitie 6.1 

(niet-formeel) Een databasetype DT is een niet-lege verzameling 
verwante functies, waarvoor geldt dat per element van het domein 
van DT de verzameling van alle beelden een tabeltype is. 
(formeel) D 

DT is een databasetype = DT f f A 


DT is een verzameling verwante functies èn 
Vd € dom(DT) [{f(d)l f € DT} is een tabeltype]. o 
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Een element van een databasetype noemen wij een database (vergelijk: 
tupel is element van tupeltype; tabel is element van tabeltvpe). 


Voorbeeld 6.1 
Het databasetvpe DT-HANDEL-1 is als volgt gedefinieerd: 


DT-HANDEL-1 = {H| H is een functie A 
dom(H) = {lev ‚art ‚ass ‚order } A 
H(lev) € TT-LEV-N A H(art) € TT-ART-N A 
H(ass) € TT-ASS-N A H(order) € TT-ORDER-N }, 


waarbij TT-LEV-N enz. als in voorbeeld 5.1. 
De hieronder weergegeven database H1 is een van de (zeer vele) 
elementen van het databasetype DT-HANDEL-1. 


H1 = 
((lev,(((Inr,5),(Inm,brakes),(ladr,pad 5),(Iwpl,eindhoven)), 
((Imr,7),(Inm,nemmer),(ladr,pad 9),(lwpl,nuenen)}, 
((Inr,23),(Inm,frein),(ladr,badweg 16) ,(lwpl,eindhoven)}}), 


(art,{{(arc,15),(anm ,¿microz),(bestadr,pad 7)), 
((arc,77),(anm,minib),(bestadr,ringbaan 5) }, 
{(arc,63), (anm,printer), (bestadr,badweg 5) }, 
((arc,50), ((anm,visdisplav),(bestadr,pad 5) }}), 


(ass, (((Inr,5),(are,77),(pr,510)), 
((lnr,23),(are,63),(pr,210)), 
((Inr,5),(arc,50),(pr:53)), 
((Inr,23),(arce,15),(pr,62)), 
((Inr,23),(arc,50),(pr,55)))), 


(order, (((onr,12),(dat ,811206),(Inr,5),(are,77),(hoev,15)), 
((onr,26),(dat,820211),(Inr,23),(arc,15),(hoev,80))))). 


Hi(lev) enz. zien er in tabelvorm als volgt uit: 


Hl(lev) = ( Inr Inm ladr lw pl 
5 brakes pad 5 eindhoven 
7 nemmer ` pad 9 nuenen 
23 frein badweg 16 eindhoven 
Hl(art) = ( arc anm bestadr 
15 microz pad 7 
77 minib ringbaan 5 
63 printer badweg 5 
50 visdisplay pad 5 
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Hl(ass) = f Inr arc pr 
5 17 510 
23 63 210 
5 50 53 
23 15 62 
Ea 50 55 
Hi(order) = í( onr dat Inr arc hoev 
12 811206 5 77 15 
26 820211 23 15 80 


In 'bestandstermen' zal elke database van DT-HANDEL-1 vier 
bestanden bevatten, en wel een leveranciersbestand H(lev), een ` 
artikelbestand H(art), een assortimentsbestand H(ass) en een order- 
bestand H(order). De inhoud van deze vier bestanden is verschil- 
lend per database. In bovengenoemd element H1 bestaat het bestand 
Hl(lev) uit drie tupels (records), het bestand Hl(art) uit vier 
tupels, het bestand H1(ass) uit vijf tupels en het bestand Hi(order) 
uit twee tupels. n 


Dom(DT), het gemeenschappelijke domein van de databases van een 
databasetype DT, noemen wij de objectverzameling van DT. Een ele- 
ment van de objectverzameling van DT noemen wij een object van DT. 
Zo is (lev,art,ass,order]) de objectverzameling van DT-HANDEL-1 
(voorbeeld 6.1). 

Onder de attributen van een object verstaan wij de attributen van 
het tabeltype dat bij het object behoort. 


Evenals bij een tupeltype, geldt ook voor een databasetype DT , dat 
er verzamelingsfuncties bestaan, zó dat voor elk van deze verzame- 
lingsfuncties geldt dat DT een deelverzameling is van het produkt. 
Zo'n verzamelingsfunctie noemen wij een databasekarakterisering 
(vergelijk: objectkarakterisering bij een tupeltype). 


Voorbeeld 6.2 


De databasekarakterisering FDT-HANDEL is als volgt gedefinieerd: 


FDT-HANDEL = ((lev,TT-LEV-N), 
(art, TT-ART-N), 
(ass, TT-ASS-N), 
(order, TT-ORDER-N)), 


waarbij de tabeltvpen TT-LEV-N enz. als in voorbeeld 5.1. 


Het is direct in te zien dat DT-HANDEL-1 van voorbeeld 6.1 een 
deelverzameling is van T(FDT-HANDEL), zelfs DT-HANDEL-1 = 
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T(FDT-HANDEL). Dus FDT-HANDEL is een cn enten 
van DT-HANDEL-1. 


Bij de behandeling van tupeltype in hoofdstuk 3 zagen wij, dat in het 
algemeen een tupeltype slechts een relatief kleine deelverzameling is 
van het produkt van de objectkarakterisering, die men als uitgangs- 
punt neemt. Dit wordt, zoals bekend, veroorzaakt door de 'inper- 
king' vanwege tupelconstraints. 

Ook het aantal mogelijke waarden van een databasetype zal 
beperkt kunnen worden en wel door zogeheten databaseconstraints. 


Een databaseconstraint is een predikaat over het produkt van een 
databasekarakterisering. 


Voorbeeld 6.3 


Over MFDT-HANDEL) van voorbeeld 6.2 worden de constraints Cl 
tot en met C4 gedefinieerd. DB € T(FDT-HANDEL). 


C1(DB) := [#(DB(lev)) < #(DB(ass)) |. 
C2(DB) := [VLEDB(order) [ 3uEDB(lev) [t(Inr) = u(Inr)] A 
SvEDB(art) [t(arc) = v(arc)]]]. 
C3(DB) := [ VELEDB (order) [ ZuEDB (ass) 
[t(Inr) = u(lnr) At(are) = u(arc)]]]. 
C4(DB) := [VEEDB(art) [t(bestadr) = Veem 6 > 
sum2e( {(u,u(hoev)) | u € DB(order) At(arc) = 
u(arc))) < 1000). D 
Opmerking 


De functie 2c levert de som van de tweede coördinaten van de paren 
(u,u(hoev)). Er zij verder opgemerkt, dat sum({u(hoev)|.... D, 
waarbij de functie sum de som levert van de getallen u(hoev), in het 
algemeen niet gelijk zal zijn aan sum2c. Als namelijk hoev in twee 
tupels van DB(order) dezelfde waarde heeft, dan zal deze waarde in 
{u(hoev) |.... Look maar eenmaal voorkomen. 


In woorden (met uiteraard het nodige risico voor dubbelzinnigheden) 
luiden bovenstaande constraints als volgt: 


C1: Het aantal leveranciers (tupels) mag niet groter zijn dan het 
aantal assortimenten(tupels). 


C2: Bij elk ordertupel moet een leverancierstupel respectievelijk 
artikeltupel voorkomen met dezelfde waarde voor het attribuut 
Inr respectievelijk arc. Met andere woorden: geen ordertupel 
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zonder dat het bijbehorende leverancierstupel respectievelijk 
artikeltupel in de database aanwezig is. 


C3: Bij elk ordertupel moet een assortimenttupel voorkomen met 
dezelfde waarde voor de attributen Inr en arc. 


C4: Van elk artikel, met besteladres Veem 6, mag het totaal aan- 
tal stuks in bestelling niet groter dan 1000 zijn. o 


De definitie van een databasetype met behulp van een databasekarak- 
terisering en een (karakteriserende) databaseconstraint vindt op 
analoge wijze plaats als de definitie van een tupeltype met behulp van 
een objectkarakterisering en een (karakteriserende) tupelconstraint. 


Voorbeeld 6.4 


Met behulp van FDT-HANDEL (voorbeeld 6.2) en de karakteriserende 
databaseconstraint C = C1 AC2 AC3 A C4 (voorbeeld 6.3) over 
M(FDT-HANDEL) kan databasetype DT-HANDEL-2 worden gedefini- 
eerd: 


DT-HANDEL-2 = (DB | DB € M(FDT-HANDEL) A C(DB) }. o 


Databasetype DT-HANDEL-2 is een echte deelverzameling van 
M(FDT-HANDEL), terwijl, zoals we reeds zagen, databasetype 
DT-HANDEL-1 gelijk is aan T(FDT-HANDEL) (voorbeeld 6.2). 
DT-HANDEL-1 is een bijzonder geval van een databasetype, namelijk 
een databasetype waarvoor geen enkele databaseconstraint geldt (dus 
formeel: C = true). Dit bijzondere geval is het gebruikelijke data- 
basetype in de bestaande database management systemen. 


Tenslotte merken we nog op dat analoog aan de kleinste objectkarak- 
terisering van een tupeltype, ook kan worden gesproken van de 
kleinste databasekarakterisering van een databasetype. 


6.2 SUBSET REQUIREMENTS 


In het vorige hoofdstuk was sprake van het behoud van informatie 
bij overgang van ongenormaliseerde tabeltypen naar genormaliseerde 
tabeltypen. Daartoe werden bepaalde attributen en afhankelijkheden 
‘ondergebracht! in andere reeds bestaande of nieuw te definiëren 
tabeltypen. Eén kwestie is daarbij echter onbesproken gebleven, 
namelijk hoe op formele wijze het verband wordt behouden tussen de 
‘verplaatste! attributen en de ‘achtergebleven! attributen. Wordt dit 
verband niet formeel vastgelegd, dan gaat informatie verloren. 
Immers, hoe zal het systeem (zonder extra maatregelen onzerzijds, 
zoals bijvoorbeeld via een toepassingsprogramma) kunnen weten dat 
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het attribuut 'Inr' van tabeltype TT-ORDER-N iets of zelfs heel veel 
te maken heeft met het attribuut 'Inr' van tabeltype TT-LEV-N. In 
het vorige hoofdstuk kozen wij voor gelijke attribuutnamen als een 
‘voorlopige! oplossing. Sommige auteurs zien dit ook inderdaad als 
de juiste oplossing, dus gelijke attribuutnamen zijn alleen toegestaan 
als deze worden toegekend aan gelijke attributen en omgekeerd. Nog 
afgezien van de vraag, wat men in zo'n geval precies dient te ver- 
staan onder gelijke attributen, is met juist genoemde oplossing het 
behoud van informatie niet gegarandeerd. Immers, zolang men er 
niet van op aan kan' dat bijvoorbeeld alle leverancierstupels, die in 
de ongenormaliseerde opzet als 'deeltupels' in een element van het 
tabeltype TT-ORDER voorkomen, in de genormaliseerde opzet als 
tupels in een element van het tabeltype TT-LEV-N zullen voorkomen, 
kan bezwaarlijk worden gesproken van behoud van informatie. Het 
zal dan ook nodig zijn formeel de nodige verbanden te leggen tussen 
tupels van verschillende ‘componenten! van een databasetype. Deze 
verbanden zullen wij leggen met behulp van speciale databasecon- 
straints, de zogeheten subset requirements. 

Alvorens nu een en ander formeel vast te leggen, zullen wij eerst 
aan de hand van een voorbeeld de zaak informeel inleiden. 

In de database H1 van DT-HANDEL-1 in voorbeeld 6.1 komen in 
H1(ass) van het attribuut 'Inr' alleen waarden voor die ook voorko- 
men in Hi(lev) als waarden van het attribuut 'Inr'. Het omgekeerde 
blijkt overigens niet te gelden. Waar wij nu naartoe willen is de vol- 
gende speciale constraint over de databases van MFDT-HANDEL) 
van voorbeeld 6.2: alleen die databases H zullen worden toegelaten, 
waarvoor geldt dat elke Inr-waarde in H(ass) ook voorkomt als Inr- 
waarde in H(lev). Met andere woorden: bij elk assortimentstupel 
moet 'te zelfder tijd' het ‘bijbehorende! leverancierstupel beschik- 
baar zijn. In voorbeeld 6.3 zijn de constraints C2 en C3 soortgelijke 
voorbeelden, bij C3 is zelfs sprake van gelijke waarden voor twee 
attributen, Inr en arc. 

Het is goed denkbaar dat voor ‘overeenkomstige! attributen van 
verschillende objecten verschillende namen worden gebruikt. 


Voorbeeld 6.5 


Stel dat FDT-HANDEL-2 gelijk is aan FDT-HANDEL van voorbeeld 
6.2 op de volgende 'vervangingen' na: 


In TT-LEV-N: 'Ino' l Di V nr! 

In TT-ASS-N: 'anr' Lpi Zepp, 

In TT-ASS-N: 'levnr' tp. Vo nr! èn 
'artk' DVi arer: 


Over T(FDT-HANDEL-2) willen wij nu 'dezelfde' constraints definië- 
ren als C1, C2, C3 en C4 van voorbeeld 6.3. C1 blijft dan ongewij- 
zigd, terwijl C2', C3', C4' komen in plaats van C2, C3, CA. 
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C2'(DB) = (vtEDB(order) [ 3u€CDB(lev)[t(Inr) = u(Ino)] A 
3veDB(art)[t(arc) = v(anr)]]]. 
C3'(DB) = [YtEDB (order) [ JuEDB(Aass) 
[t(Inr) = u(levnr) A t(arc) = u(artk)]]]. 
C4'(DB) = [ vteDB(art)[t(bestadr) = Veem 6 > 


sum2c(1(u,u(hoev))l u € DB(order) A 
t(anr) = u(arc)}) < 100011. n 


In voorbeeld 6.5 is sprake van zogeheten attributentransformatie, 
kortweg attribtrafo. 

Een attribtrafo is een functie, die twee verzamelingen van attri- 
buten éénéén-duidig op elkaar afbeeldt. Zo zijn de functies fl, f2 
en f3 met f1 = ((Inr,inr)), f2 = ((Inr,lno) } en f3 = ((Inr,levnr), 
(are,artk)) attribtrafo's. 

Meer formeel: een attribtrafo is een functie, waarvoor geldt: 


- dom(f) = Al; rng(f) = A2; 
— A1 en A2 zijn attributenverzamelingen 
- ALI = IAZI. 


Wij spreken ook wel van een attribtrafo van Al naar A2. 


Wij zijn nu toe aan de definiëring van het begrip subset require- 
ments. Hierbij dient goed in het oog te worden gehouden dat, als 
DK een databasekarakterisering is en OB een object van DK, de uit- 
drukking DK(OB) een tabeltype voorstelt. Het is dus zinvol te spre- 
ken van de attributenverzameling van DK(OB). Zo is (zie voorbeeld 
6.2) de attributenverzameling van FDT-HANDEL(art) gelijk aan 
(are,anm,bestadr) (zie voorbeeld 5.1). 


Definitie 6.2 
Zij: DK: een databasekarakterisering, 
OB1,0B2: twee objecten van DK, 
Al,A2: een deelverzameling van de attributenverzameling van 
DK(OB1),DK(OB2), 
f: een attribtrafo van Al naar A2. 


(niet-formeel) De databaseconstraint C is een subset requirement 
vanuit Al van OB1 naar A2 van OB2 met f, als voor elke database 

van M(DK), die aan C voldoet, geldt dat bij elk tupel van OBI een 
tupel van OB2 voorkomt, zó dat A2 en Al gelijke waarden hebben 

voor elk paar attributen, dat volgens f bij elkaar hoort. 

(formeel) C is een subset requirement vanuit Al van OBI naar A2 


van OB2 met f Ë 


C(DB) = [vt € DB(OB1) //A1 
[ ((f(al),t(al))l al € A1} € DB(OB2) //A2]]. D 
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Voor subset requirement zullen wij verder de afkorting ssr gebrui- 
ken. 

Voorbeeld 6.6 

C2 van voorbeeld 6.3 bevat twee ssr's, namelijk 

1. vanuit {Inr} van order naar {Inr} van lev met f = {(Inr‚Inr) }, 


2. vanuit {arc} van order naar {arc} van art met f = {(arc,‚arc) }. 


C3 van voorbeeld 6.3 is een ssr 
vanuit (Inr,arc) van order naar (Inr,arc) van ass met 


f = {(Inr,‚lnr),(arc,‚arc) }. 


C3' van voorbeeld 6.5 is een ssr 
vanuit ilnr,arc) van order naar {levnr,artk ) van ass met 


f = ((Ilnr,levnr),(are,artk)). o 


Opmerking bij definitie 6.2 
Als A2 een sleutel is van DK(OB2), dan noemt men A1 een 
referentiesleutel (foreign key) ten opzichte van A2. 


6.3 GENORMALISEERD DATABASETYPE 


In het vorige hoofdstuk hebben wij het begrip genormaliseerd 
tabeltype ingevoerd. Met behulp hiervan kunnen wij de definitie 
geven van een zogeheten genormaliseerd databasetype. 


Definitie 6.3 | 
(niet-formeel) Een databasetype DT is genormaliseerd als de tabel- 
typen die bij de objecten horen alle genormaliseerd zijn. 

(formeel) Een databasetype DT is genormaliseerd 


p [VOB € dom(DT)( het tabeltype van OB is genormaliseerd)). o 


Voorbeeld 6.7 


Databasetype DT-HANDEL-1 van voorbeeld 6-1 is genormaliseerd, 
want de bij de objecten lev, art, ass en order behorende tabeltypen 
TT-LEV-N, TT-ART-N, TT-ASS-N en TT-ORDER-N zijn genormali- 
seerd (zie voorbeeld 5.1). 

Zo is ook databasetype DT-HANDEL-2 van voorbeeld 6.4 genor- 
maliseerd. o 
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Bij overgang van ongenormaliseerd databasetvpe naar genormali- 
seerd databasetvpe, is de normalisatie geen voldoende voorwaarde 
voor behoud van informatie. Hiervoor zullen nog de nodige voorzie- 
ningen moeten worden getroffen met behulp van ssr's, en wel vol- 
gens onderstaand voorschrift. 

Als databasetvpe DTN genormaliseerd is en minstens dezelfde 
informatie bevat als databasetvpe DT, dan moet aan de volgende 
voorwaarden zijn voldaan: 

- DIN bevat alle attributen en afhankelijkheden van DT. 
- Voor elke afhankelijkheid, die de normalisatie van DT verstoort, 
is in DTN een ssr gedefinieerd. 


Voorbeeld 6.8 


Stel DT-HANDEL-0 is het databasetype met 'order' als enig object en 
TT-ORDER van voorbeeld 4.3 als tabeltype behorende bij dit object. 
Dan is duidelijk dat DT-HANDEL-0 een ongenormaliseerd database- 
type is. 

DT-HANDEL-1 van voorbeeld 6.1 is weliswaar een genormaliseerd 
databasetype, maar 'omvat' niet de informatie van DT-HANDEL-0 
vanwege het ontbreken van ssr's. DT-HANDEL-2 van voorbeeld 6.4 
is echter wel een genormaliseerd databasetype, dat de geschikte 
ssr's bevat om de informatie van DT-HANDEL-0 te omvatten. (Men 
ga dit na; zie ook opgave 6.2b3). D 


OPGAVEN 


6.1 (H1 en DT-HANDEL-1 als in voorbeeld 6.1; 
DT-HANDEL-2 als in voorbeeld 6.4; 
FDT-HANDEL als in voorbeeld 6.2). 


a. Behoort database H1 tot databasetvpe DT-HANDEL-2? 


b. Gegeven de databases H2, H3, H4, H5 van T(FDT-HANDEL) 
met onderstaande definities : 


H2: H2/(lev,art,orderj) = H1/flev,art,order) èn H2(ass) = f 
H3: H3(lev) = H3(art) = H3(ass) = H3(order) = Í 
H4: H4/Tlev,art,ass) = H1/Tlev,art,ass) èn H4lorder) = f 
H5: H5(lev) = Hi(lev) U {{(Inr,18), (Inm,‚frein), 

(ladr ‚plein 17), (lwpl,‚geldrop) }}. 


Ga voor elk van deze vier databases na of zij behoren tot 
databasetype DF-HANDEL-2. 
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c. Geef de volgende databaseconstraints C5 en C6 over 
T(FDT-HANDEL) in woorden weer: 


C5(DB) :- [#({t| t € DB(order) A 
800101 < t(dat) < 800601 A 
Ju € DB(lev)[t(Inr) = u(lnr) A 
u(lwpl) = eindhoven))) < 100]. 


C6(DB) := [Yt € DB(ass)[t(pr) > 500 > 
vu € DB(order)[ (u(lnr) =t(Inr) A 
u(arc) = t(arc)) = u(hoev) < 25] 1. 
d. Geef de volgende databaseconstraints over M(FDT-HANDEL) 
formeel weer. 
di. Het aantal orders in januari 1981 voor besteladres 
Mag 8' mag niet groter zijn dan 20. 


d2. Orders in januari 1981 kunnen niet worden afgeleverd 
op besteladres 'Veem 13'. 


6.2 (bij voorbeeld 6.3) 
a. Welke van onderstaande databaseconstraints Ca, Cb, Cc, is 
equivalent met C3? 


Ca(DB) := [Yt € DB(order)[ äu € DB(ass) 


[t/{Inr‚are} = u/{lnr,arc}]]]. 


Cb(DB) := [ vt € DB(ass) [3u € DB(order) 
[t(Inr) = u(lnr) At(are) = u(arc)]]]. 


Ce(DB) := [Jt € DB(order)[ vu € DB(ass) 
[t(Inr) = u(lnr) At(are) = u(arc)]]]. 


b. Gegeven de databaseconstraint C7: 
C7[DB] := [Yt € DB(ass)[3u € DB(lev)[u(lnr) =t(Inr)] A 
iv € DB(art)[v(arc) = t(arc)]]]. 


bi. Ga na dat C7 een ssr is. 

b2. Geldt: (C2 a C3)(DB) > C5(DB)? 

b3. Gegeven DT-HANDEL-3 = 
{DB| DB € M(FDT-HANDEL A (C2 A C7)(DB)}. 
Is DT-HANDEL-3 een databasetype met minstens dezelf- 
de informatie als DT-HANDEL-0 (voor voorbeeld 6.8)? 
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6.3 Een verzekeringsmaatschappij wil een database bouwen ten 
behoeve van een efficiënte informatievoorziening bij het afslui- 
ten en behandelen van polissen. Daartoe zijn de volgende spe- 
cificaties opgesteld. 

De verschillende verzekeringssoorten zijn ingedeeld in (elkaar 
niet-overlappende) klassen. Voorbeelden van klassen zijn: de 
klasse van autoverzekeringen, de klasse van ziektekostenver- 
zekeringen. Voorbeelden van verzekeringssoorten binnen de 
klasse van autoverzekeringen zijn: all-risk verzekering, W.A.- 
verzekering. Per verzekeringssoort zullen in het algemeen vele 
polissen worden afgesloten. ` 

Elke klasse valt onder de verantwoordelijkheid van een of meer 
medewerkers. Deze verantwoordelijkheid houdt in dat informa- 
tie over de desbetreffende klasse aan klanten kan worden ver- 
strekt en dat polissen voor verzekeringssoorten van de desbe- 
treffende klasse mogen worden afgesloten. 

Per polis is precies één medewerker verantwoordelijk voor 
afsluiting en behandeling van deze polis. 

De mate van deskundigheid van een medewerker kan per klasse 
verschillend zijn. 

De volgende gegevens moeten via de database beschikbaar kun- 
nen komen (met in hoofdletters: voorstel voor eventueel beno- 
digde namen). 


Per klasse (KL): | 
klassecode (KC, uniek), klassebeschrijving (KB), naam 
(MNM) van elke verantwoordelijke medewerker en diens mate 
van deskundigheid (DSK) voor de desbetreffende klasse. 

Per verzekeringssoort (VERZ): 

KC (van klasse), subcode (SUBC, uniek binnen KC), 
beschrijving (VB), aantal afgesloten polissen in elk van de 
jaren 1977, 1978, 1979 (APV7, APV8, APV9). 

Per nedewerker (MEDEW ): 
naam (MNM, uniek), kantooradres (KADR), kantoorwoon- 
plaats (KWPL), privċ-adres (PADR), privċ-woonplaats 
(PWPL), telefoonnummer kantoor (TELK), telefoonnummer 
privé (TELP), aantal afgesloten polissen in elk van de jaren 
1977, 1978, 1979 (APM7, APM8, APM9). 

Per klant (KLANT) 
klantnummer (KLNR, uniek), naam (KNM), adres (KADR), 
woonplaats (KWPL), aantal geldige polissen (AGP). 

Per informatieverstrekking (INFVSTR): 

KC (van klasse), naam (IMNM) van medewerker, mate van 
deskundigheid (IDSK) van medewerker voor de klasse, 
hoogst mogelijke mate van deskundigheid (HDSK) binnen de 
klasse, klantnummer (IKLNR) van een bestaande klant, 
datum (DAT), manier van communicatie (MC, bijvoorbeeld 
per brief of telefoon). 
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Voor de unieke identificatie van een informatieverstrekking 
is de combinatie (KC, IMNM, IKLNR, DAT) nodig. 

Per polis (POL): 
klassecode (PKC) van klasse, subcode (PSUBC) van verze- 
keringssoort, naam (PMNM) van medewerker, klantnummer 
(PKLNR) van bestaande klant, volgnummer (VNR, nodig 
omdat een klant van eenzelfde verzekeringssoort meer dan 
een polis kan afsluiten), premie (PR), afsluitingsdatum 
(PDAT ), looptijd (LPT, na het verstrijken van de looptijd is 
de polis ongeldig). 


Ontwerp een genormaliseerd databasetype voor bovenstaande 
specificaties. Zonodig zelf hiaten in de semantiek van de gege- 
vens aanvullen. 


7 UITGEBREID VOORBEELD VAN EEN 
GENORMALISEERD DATABASETYPE 
(ziekenhuis-database) 


Hieronder volgt de definitie van een genormaliseerd databasetvpe, 
waarbij in opeenvolgende delen van voorgaande type-definities 
gebruik wordt gemaakt. In de kolom toelichtingen wordt de beteke- 
nis van de onderdelen toegelicht. 

Bij deze definitie zullen wij gebruik maken van onderstaande 
syntax: 


1. subrange, array en record als in Pascal. 
bject 


2. TT = objec 
kar OK 
tuc C(t) 
tac C(D) 
keys SL 


endobject 


voor de definitie van tabeltype TT, met objectkarakterisering OK 
èn 


tupelconstraint C(t) (t € M(OK)), èn 
tabelconstraint C(D) (D € P(MT); MT kleinste 

— karakteriserend tupeltvpe), èn 
sleutelverzameling SL. 


facultatief Í 


3. DT = database 
kar DK ` 
ssr (O1.A1,02.A2,f) 
dac C(DB) 
enddatabase 


voor de definitie van databasetype DT, met databasekarakterise- 
ring DK èn de ssr's vanuit Al van O1 naar A2 van O2 met f (id: 
identieke afbeelding) ën databaseconstraint C(DB) (DB € T(DK)). 
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OPGAVEN 


1.1 Geef alle tupelconstraints (tuc's), tabelconstraints (tac's) en 
databaseconstraints (dac's) van ziekenhuis verbaal weer. 


1.2 Geef de eerste, derde en negende ssr (subset requirement) van 
ziekenhuis weer in de vorm van een databaseconstraint. 


7.3 Geef commentaar/antwoord op de volgende beweringen/vragen. 


a. 


~> mr Go 


WE ES 


Een verpleegkundige uit Geldrop kan niet behoren tot afde- 
ing 9. 


. Afdeling 9 moet minstens vier verpleegsters hebben. 


Elke verpleegkundige uit Eindhoven behoort tot afdeling 9. 


. Kan een specialist tot meer dan één afdeling horen? 


Een patiënt kan voor meer dan één reden worden opgenomen. 
Worden alleen de 'lopende' opnamen bijgehouden? 


. Een patiënt is iemand, die een opname en/of een behandeling 


en/of een medicijnverstrekking heeft ondergaan. 


. Het tarief van een behandeling ligt vast door de soort. 


Het tarief van een behandeling ligt vast door de combinatie 
van behandelcode en behandelende specialist. 


-Kan worden nagegaan of een specialist actief is geweest? 
. Idem voor een verpleegkundige? 


De medicijnen met code M12 en M13 moeten altijd worden 
voorgeschreven voor 5 dagen, 3 maal per dag en 2 stuks per 
keer. 


. Per medicijnverstrekking liggen aantal dagen, frequentie 


per dag en aantal stuks per keer vast. 


. Kan een specialist een patiënt zijn? 
. Van elke patiënt is bekend hoeveel malen opname voor 


informaritis severus' heeft plaatsgevonden. 


1.4 Ga na voor elk van de vijf onderstaande beweringen a, b, c, d 
en e, of zij in strijd is met de type-definitie van ziekenhuis. 
Zo ja, dan moeten alle redenen van deze strijdigheid worden 
gegeven. De variabele zkh is van het type ziekenhuis. 


a. 
b. 


C. 


#((t(vkanr) | t € zkh(vk))) = 

#((t(vknr) | t € zkh(vk()) = 

zkh(beh) > (((bcd,c1),(bnm,kno6),(bsrt,kno),(btar,05)], 
((bed,c2), (bnm,kno6), (bsrt,kno), (btar ,80) }}. 


d. zkh(opn)//(pnr,indat,uitdat) = 


{{(pnr,15), (indat ,791207), (uitdat ,800407) }, 
{(pnr,15), (indat,791223), (uitdat ,800307))). 
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e. it(pnr) l t € zkh(opn)) 2 {15,20,30} A 
(t(pnr) | t € zkh(p)} = {6,7,8,15,30,43}. 


1.5 Bij deze opgave wordt bij elk van de drie onderdelen a, b en c 
telkens opnieuw uitgegaan van de ziekenhuis-database, zoals 
gedefinieerd in dit hoofdstuk. 

Ga voor elk van de onderdelen na, welke veranderingen in de 
database-definitie nodig zijn om (met behoud van normaliteit) 
te voldoen aan het gestelde. 


a. Eenzelfde behandeling kan op eenzelfde datum op eenzelfde 
patiënt niet meer dan eenmaal plaatsvinden. 

b. Voor behandelingssoort bsrt = ACDC geldt een vast tarief 
btar = 40. 

c. Voor elke behandelsoort geldt een eigen vast tarief. 


8 GEBRUIK EN ONDERHOUD VAN EEN 
DATABASE; VRAAGTALEN 


8.1 INLEIDING 


In voorgaande hoofdstukken hebben wij gezien hoe op een ‘nette! 
genormaliseerde wijze de structuur van de gegevens kan worden 

vastgelegd. Om vervolgens ook werkelijk een (fysiek opgeslagen) 
database ter beschikking te hebben, zal 

— de opslag- en fysieke structuur moeten worden vastgelegd, en 
— de database moeten worden 'geladen'. 


Met het laden van een database wordt bedoeld: het opslaan van de 
tupels van alle actuele objectoccurrences in het daarvoor aangewe- 
zen (achtergrond)geheugen. 

Het is eigenlijk niet de bedoeling dat in dit boek de opslag- en 
de fysieke structuur ter sprake komen en zeker niet het laden van 
een database. Hiermee wil niet gezegd zijn dat deze onderwerpen 
niet belangrijk zouden zijn. Integendeel, een goed inzicht in deze 
zaken is noodzakelijk om met name een goede 'performance' tijdens 
gebruik en onderhoud van een database mogelijk te maken. Genoem- 
de beperking wordt voor dit boek aangehouden, omdat gebleken is 
dat het vastleggen van de logische structuur van de gegevens en de 
manipulatie met de gegevens op hetzelfde logische niveau een duide- 
lijk afgerond onderwerp is van een zodanige omvang en moeilijkheids- 
graad, dat aparte behandeling ervan in een boek ten volle gerecht- 
vaardigd is. Overigens zullen wij er in deel III (netwerkmodel) toch 
niet aan kunnen ontkomen om met name de opslagstructuur nog vrij 
uitgebreid aan bod te laten komen. Ter plaatse zal duidelijk worden 
gemaakt waarom dit nodig is. 


In dit hoofdstuk zullen wij ons dus beperken tot manipulatie van de 
gegevens op logisch niveau, dus op het niveau zoals wij ze kennen 
via de definitie van de logische structuur. 
Bij de manipulatie onderscheiden wij, zoals reeds in $ 1.3 werd 
opgemerkt 
- onderhoud (Engels: maintenance), dat wil zeggen invoegen van 
nieuwe tupels, veranderen of verwijderen van bestaande tupels; 
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- gebruik (Engels: retrieval) van gegevens. 


Gebruik van gegevens is uiteraard de uiteindelijke doelstelling. Maar 
om steeds de juiste gegevens ter beschikking te hebben, zal over 
het algemeen veelvuldig onderhoud nodig zijn. Men bedenke namelijk 
dat de informatiebehoefte dikwijls bij voorkeur betrekking heeft op 
(in de loop der tijd) veranderende gegevens. Zinvol gebruik dient 
dan ook vooraf te worden gegaan door adequaat onderhoud. 

Overigens menen wij er in dit boek op didactische gronden beter 
aan te doen eerst het gebruik en dan het onderhoud te behandelen. 
Alvorens nu met het gebruik (retrieval) te beginnen, eerst nog 
enkele opmerkingen over zogeheten vraagtalen. 


Elke zichzelf respecterende leverancier van een DBMS zorgt er 
heden ten dage voor dat hij een vraagtaal (Engels: query-language) 
ter beschikking heeft (SQL, IQL, Query by Example, enz., enz.). 
De bedoeling van zo'n vraagtaal is dat de gebruiker op een 'user- 
friendly! manier gebruik kan maken van de database. De benaming 
'vraagtaal' is overigens nogal misleidend, want met de geboden faci- 
liteiten kan meestal ook onderhoud worden gepleegd op de database. 

Experimenten met beschikbare vraagtalen hebben duidelijk aange- 
toond dat deze talen toch nog alle van zodanige gebruiksvreemde 
opzet zijn, dat er bij een iets meer dan elementaire vraag gemakke- 
lijk fouten in kunnen sluipen. Eigenlijk zijn zulke fouten niet te wij- 
ten aan de vraagtaal in kwestie. Een vraagtaal is in eerste instantie 
een neutraal instrument, dat zowel goed als slecht kan worden 
gebruikt. Vergelijk goede en slechte programma's in overigens res- 
pectabele programmeertalen. De eigenlijke oorzaak van genoemde 
fouten is veeleer te zoeken in een gebrek aan verzamelingstheoretisch 
„inzicht in de gestelde vragen. 

Immers, waar gaat het eigenlijk om bij de beantwoording van een 
vraag. Er wordt dan een verzameling gegevens gevraagd, die is af 
te leiden uit de verzameling gegevens, die in de database ligt opge- 
slagen. Onze ervaring is dan ook dat gebruik van vraagtalen veel 
betrouwbaarder wordt, als men de (ge)vraag(de verzameling) for- 
meel in een verzamelingsexpressie weet weer te geven. Wij zullen 
daarom vragen (eerst) weergeven in de vorm van verzamelingsex- 
pressies, waarbij dan enkele primitieve 'taalelementen' zullen worden 
gebruikt. Men bedenke echter, dat er dan geen sprake is van een 
echte, geïmplementeerde taal. Wat betreft transformatie van de 
gevonden verzamelingsexpressies naar een weergave in een geimple- 
menteerde taal, zullen wij aan het einde van dit hoofdstuk voorbeel- 
den geven van transformatie in de vraagtaal SQL en in deel III 
enkele voorbeelden van transformatie in de DML van het netwerkmo- 
del. 
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8.2 GEBRUIK (RETRIEVAL) 


Wat betreft te gebruiken taalconstructies zullen we ons tot de vol- 
gende drie kunnen beperken: 


1. get (SE) SE = set expression (verzamelingsexpressie) 
2. def deflist deflist = lijst van (nieuwe) verzamelingen en/of 


variabelen (zie voorbeeld 8.7 en 8.8) 
3. f*(t) ext db (ob) betekenis van en nadere toelichting op deze 
expressie bij voorbeeld 8.10 en 8.11. 


Een en ander moge verder duidelijk worden uit de behandeling van 
onderstaande voorbeelden, die alle betrekking hebben op het in 
hoofdstuk 7 gedefinieerde databasetype. De variabele zkh is van dit 


type. 
Voorbeeld 8.1 
Vraag 


Geef naam, adres en woonplaats van de specialisten, die tot afdeling 
9 behoren en over meer dan twee bedden kunnen beschikken. 


Antwoord 
get ((t/isnm,sadr,swpl) l t € zkh(sp) A 
t(spanr) = 9at(ab) > 2)). D 


Voor het volgende voorbeeld moeten tabellen van verschillende tabel- 
typen worden geraadpleegd. 

Voorbeeld 8.2 

Vraag 


Geef naam, adres en woonplaats van de specialisten, die de behande- 
ling met code KNO6 hebben verricht. 


Antwoord 
get ((t/isnm,sadr,swpl) | t € zkh(sp) A 
JuEzkh(pb) [u(snr) = t(snr) A u(bed) = KNO6] ).. D 


Tussen de vragen van de volgende twee voorbeelden dient goed het 
verschil te worden gezien. De 'of'-voorwaarde van voorbeeld 8.3 
(systologitis òf infologitis) vraagt om een andere aanpak dan de 'en'- 
voorwaarde van voorbeeld 8.4 (svstologitis èn infologitis). 
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Voorbeeld 8.3 
Vraag 


Geef naam, adres en woonplaats van de patiënten die in 1980 werden 
opgenomen voor svstologitis of infologitis . 


Antwoord 1 
get (it/(pnm,padr,pwpl) l t € zkh(p) A 
duEzkh(opn)(u(pnr) = t(pnr) A 800101 < u(indat) < 801231 A 
u(opnr) € {systologitis ,;infologitis )) }). 
Uiteraard is het nu volgende antwoord ook goed, maar in geval er 


(veel) meer dan twee opnameredenen in het geding zijn, is een ant- 
woord analoog aan antwoord 1 natuurlijk eenvoudiger 


Antwoord 2 
get (it/(pnm,padr,pwpl) | p € zkh(p) A 
gu€zkh(opn)[u(pnr) = t(pnr) A'800101 < u(indat) < 801231 A 
(u(opnr) — svstologitis v 
u(opnr) = infologitis)))). o 


Voorbeeld 8.4 
Vraag 


Geef naam, adres en woonplaats van de patiënten die in 1980 werden 
opgenomen voor systologitis èn voor infologitis. 


Antwoord 1 
get ({t /{pnm,padr,pwpl} | t € zkh(p) A 
{systologitis ,infologitis } c 
{u(opnr) | u € zkh(opn) A u(pnr) = 
t(pnr) a 800101 < u(indat) < 801231}}). 
Onderstaand antwoord 2 is ook goed, maar in geval er (veel) meer 


dan twee opnameredenen in het geding zijn, geldt ook hier weer dat 
een antwoord analoog aan antwoord 1 veel eenvoudiger is. 


Antwoord 2 
get ({t /(pnm,padr,pwpl) | t € zkh(p) ^ 
du,v € zkh(opn)[u(pnr) = v(pnr) =t(pnr) A 
800101 < u(indat) < 801231 A 800101 < u(indat) < 801231 ^ 
u(opnr) = systologitis A v(opnr) = infologitis ] }). o 
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In de voorwaarden, waaraan tupels van een tabel moeten voldoen, 

kunnen optreden: 

— het aantal elementen van een verzameling ; 

- de som, het gemiddelde, het maximum, het minimum van een ver- 
zameling waarden. 

Hiervoor zullen wij gebruik maken van de volgende functies: 


# (reeds bekend) voor het aantal elementen van een verzame- 
ling 
sum som 
max maximum A 
à voor Wë n een verzameling waarden 
min wa minimum EE A E wan 
average gemiddelde 


Als een bepaalde waarde meer dan eens in dezelfde tabel kan optre- 
den (hetgeen voor attributen die geen sleutel zijn altijd mogelijk is), 
zal men voor het bepalen van som en gemiddelde gebruik moeten 
maken van de functies: sum2c en average2e. Voor de toelichting 
hierop zij verwezen naar constraint C4 in voorbeeld 6.3. 

Voorbeeld 8.5 

Vraag 


Geef naam, adres en woonplaats van elke specialist, die in 1980 meer 
dan 10 maal de behandeling KNO7 heeft verricht en die voor deze 
behandeling in 1980 gemiddeld meer dan een half uur nodig had. 


Antwoord 
get (1t/isnm,sadr,swpl) | t € zkh(sp) A 
#({u l u € zkh(pb) Au(snr) =t(snr) A 
800101 < u(dat) < 801231 A u(bed) = KNO7}) > 10 A 
averageżc(((u,u(duur)) | u € zkh(pb) A 
800101 < u(dat) < 801231 Au(bed) = KNOT A 
u(snr) = t(snr))) > 30}). o 
Bovengenoemde functies kunnen niet alleen onderdeel vormen van 
een voorwaarde, maar ook van het gevraagde zelf, zoals in het vol- 
gende voorbeeld. 
Voorbeeld 8.6 
Vraag 


Geef van elke specialist, die in 1980 meer dan 10 maal de behandeling 
KNO7 heeft verricht: naam, adres, woonplaats, het aantal malen dat 

hij deze behandeling heeft verricht in 1980 en de maximale en gemid- 
delde duur van dit aantal. 
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Antwoord 
get ({(t /isnm,sadr,swpl), 
#({u l u € zkh(pb) Au(snr) =t(snr) A u(bed) = KNOT A 
800101 s u(dat) s 801231)), 
max({u(duur) | u € zkh(pb) Au(snr) = t(snr) A 
.U(bed) = KNO7 A 800101 < u(dat) < 801231)), 
averageżce(((u,u(duur)) | u € zkh(pb) A 
u(snr) =t(snr) A u(bed) = KNOT A 
800101 < u(dat) < 801231))) | t € zkh(sp) A 
#({ u l u € zkh(pb) Au(snr) =t(snr) A 
u(bed) = KNO7 A 800101 < u(dat) < 801231)) > 10)). 


Voor een ander antwoord op deze zelfde vraag, zie voorbeeld 8.8. o 


Expressies, zoals in bovenstaand voorbeeld, zijn zo omvangrijk en 
ingewikkeld, dat ‘splitsing’ in 'tussenverzamelingen' eigenlijk moge- 
lijk zou moeten zijn. Zo'n splitsing is inderdaad mogelijk via aparte 
definities in het def-gedeelte. Wij zullen dit duidelijk maken aan de 
hand van het volgende voorbeeld. Verder wordt dan in voorbeeld 
8.8 een alternatieve oplossing gegeven van de vraag in voorbeeld 
8.6. 


Voorbeeld 8.7 
Vraag 


Geef naam, adres en woonplaats van de specialisten, die in 1980 min- 
stens eenmaal behandeling B13 hebben uitgevoerd, zodanig dat deze 
behandeling langer duurde dan enige behandeling B13 in 1979 door 
welke specialist ook. 


In antwoordi wordt een oplossing gegeven zonder 'splitsing', dus 
zonder een def-gedeelte met aparte definities. In antwoord2 wordt 
wel gewerkt met een def-gedeelte. 


Antwoord 1 | 
get (it/(snm,sadr,swpl) | t € zkh(sp) A 
du € zkh(pb)[u(snr) = t(snr) A 800101 < u(dat) < 801231 ^ 
u(bed) = B13 A u(duur) > 
max({v(duur) l v € zkh(pb) Av(bed) = B13 A 
790101 < v(dat) < 791231))1)). 


IA 


100 


Antwoord 2 
def H :- (t/isnr,duur) | t € zkh(pb) A 
800101 < t(dat) < 801231 At(bed) = B13}; 
maxd79 :- max(it(duur) | t € zkh(pb) A 
t(bed) = B13 A 790101 < t(dat) < 791231)) 


get ((t/(snm,sadr,swpl) | t € żkh(sp) A 


Ju € H(u(snr) =t(snr) Mu(duur) > maxd79]}). D 


Voorbeeld 8.8 
Vraag 
Als in voorbeeld 8.6. 
Antwoord | 
def H := (t/(bed,pnr,dat,duur,snr) l t € zkh(pb) A 
800101 s t(dat) s 801231))) 
get (((t/(snm,sadr,swpl), #({u l u € H Au(snr) = t(snr))), 
max({u(duur) | u € H Au(snr) = t(snr))), 
average?2e( ((u,u(duur)) | u € H Au(snr) = t(snr)))) | 
t € zkh(sp) A#({u | u € H Au(snr) =t(snr)}) > 10}). o 
In het databasetype van hoofdstuk 7 zijn vele ssr's (subset require- 
ments) gedefinieerd. Deze garanderen, zoals gezegd, dat naast 
tupels van een bepaald object andere tupels van een ander object 
beschikbaar zullen zijn. 
Voorbeeld 8.9 
Vraag 


Geef naam, adres en woonplaats van de specialisten, die in december 
1980 verantwoordelijk zijn geweest voor een opname van een patiënt 
uit Eindhoven. 


Antwoord 
get ( (t {snm ‚sadr ‚swpl} | t € zkh(sp) A 
Ju € zkh(opn)( 801201 < u(indat) < 801231 A 
u(snr) =t(snr) A 
3v € zkh(p)[v(pnr) = u(pnr) A 
v(pwpl) = eindhoven)))). o 
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In bovenstaand voorbeeld 'klinkt het een beetje overdreven', dat als 
conditie wordt gesteld: ''3vEzkh(p) (v(pnr) = u(pnr)...', terwijl wij 
vanwege de subset requirement (opn.ipnr),p.(pnr), id) zeker 
weten dat er zo'n p-tupel moet zijn. Ofschoon bovenstaand antwoord 
niet fout is, gaan we toch meer expliciet gebruik maken van de 
ssr's. We zullen dit eerst demonstreren aan een voorbeeld, en dan 
een algemene aanpak schetsen. 


Stel: pat is de attribtrafo ((pnr,pnr)), en t is een tupel, waarin 
pnr als attribuut voorkomt zoals een opname- of een patiëntbehande- 
lingstupel. Wij definiëren nu de zogeheten sterfunctie pat* als volgt: 


pat*(t) :- ((pat(pnr),t(pnr))), dus 

pat*(t) :- ((pnr,t(pnr))). 
Met pat*(t) ligt nu precies één tupel vast van het type patiënt, daar 
{pnr } sleutel is van patiënt. We kunnen pat*(t) dus eenduidig 'uit- 


breiden! tot een patiċnttupel en deze uitbreiding wordt nu bedoeld 
met de uitdrukking: 


pat'(t) ext zkh(p). 
Dus (pat*(t) ext zkh(p)) is het patiënttupel t mat t(pnr) als waarde 
voor de sleutel pnr. Dan is dus ook: 
(pat*(t) ext zkh(p))(pwpl) = eindhoven 
een syntactisch juiste bewering. 
Met behulp van het bovenstaande kunnen wij nu een antwoord geven 
voor de vraag in voorbeeld 8.9, waarbij expliciet gebruik wordt 
gemaakt van een van de ssr's (met bijbehorende attribtrafo). 
Voorbeeld 8.10 
Vraag 
Als in voorbeeld 8.9. 
Antwoord 
get (1t/(snm,sadr,swpl) | t € zkh(sp) A 
Ju € zkh(opn)( 801201 < u(indat) < 801231 A 
u(snr) =t(snr) A 
(pat*(u) ext zkh(p))(pwpl) = eindhoven] )). 


D 


Na bovenstaand voorbeeld zullen wij nu het gebruik van ssr's door 
middel van sterfuncties algemeen behandelen voor een databasetype. 
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Zij gegeven databasetype DT en de variabele DB van dit type. 
Verder is f een attribtrafo met dom(f) = Al en rng(f) = A2. De ster- 
functie ff wordt nu als volgt gedefinieerd : 


— dom(f*) is de verzameling van alle tupels u, waarvan de attribu- 
tenverzameling Al bevat èn 
— f*(u) = ((f(a),u(a)) l a € Al}. 


Als f nu gebruikt wordt in een ssr vanuit Al van OB1 naar A2 in 
OB2, zodanig dat Al een referentiesleutel is ten opzichte van A2, 
dan bepaalt f*(u) een sleutelwaarde van OB2. Met 


f'(u) ext DB(OB2) 


wordt dan bedoeld: het door f*(u) uniek bepaalde tupel van 
DB(OB2). 


Van het bovenstaande zullen wij gebruik kunnen maken bij het 
oplossen van vragen op de ziekenhuis-database. De in hoofdstuk 7 
gebruikte attribtrafo's bij de ssr-definities zullen wij als volgt vast- 
leggen: 


pat = i(pnr,pnr)) 

vk = ((vknr,vknr)) 

spec := ((snr,snr)) 

afdl :- ((vkanr,anr)) 

afd2 :- ((spanr,anr)) 

afd3 :- {(vanr,‚anr)} 

vr z ((vnr,vnr)) 

opn = ((pnr,pnr),(indat,indat)) 
beh = {(bed,bed) } 

med = ((mcd,mcd)). 


Bij al deze attribtrafo's is Al een referentiesleutel ten opzichte van 
A2, Dit is niet toevallig, aangezien ziekenhuis een genormaliseerd 
databasetype is. Bij een genormaliseerd databasetype zijn eigenlijk 
alleen die ssr's zinvol, die uniek 'heen wijzen! naar tupels van ande- 
re objecten. 

In het diagram op p.103 zijn de bijbehorende sterfuncties (pat*, 
enz.) weergegeven. 


We zullen deze paragraaf nu besluiten met een voorbeeld, waarin 
tuitbundig' gebruik kan worden gemaakt van sterfuncties en waarin 
ook het 'nesten' van sterfuncties voorkomt. 


Voorbeeld 8.11 
Vraag 


Geef van elke behandeling die in mei 1980 werd verricht door een 
specialist van de afdeling dermatologie: behandelcode en -soort , 
patiëntnummer en -naam, datum, specialistnummer en -naam. 
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Figuur 8.1 Diagram van ziekenhuis-database met sterfuncties. 


Antwoord 


get ((((bed,t(bed), 
(bsrt, (beh*(t) ext zkh(beh))(bsrt)), 
(pnr,t(pnr)), 
(pnm,(pat'(t) ext zkh(p))(pnm)), 
(dat,t(dat)), 
(snr,t(snr)), 
(snm,(spec')(t) ext zkh(sp))(snm))) | 


t € zkh(pb) A 800501 < t(dat) < 800531 A 
(afd2*(spec*(t) ext zkh(sp)) ext zkh(afd))(anm) = 
dermatologie )). o 
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8.3 ONDERHOUD (MAINTENANCE) 


In $ 8.1 werd reeds vermeld dat onderhoud (maintenance) omvat 
- invoegen van nieuwe tupels en/of j 

- veranderen van bestaande tupels en/of 

- verwijderen van bestaande tupels. 


Evenals bij de behandeling van retrieval in de vorige paragraaf zul- 
len wij bij de behandeling van onderhoud gebruik maken van verza- 
melingsexpressies tezamen met enkele primitieve 'taalelementen'. Ook 
hier bedenke men weer, dat er met deze taalelementen geen sprake 
is van een echte, geimplementeerde taal. 


Wij zullen gebruik maken van de volgende taalconstructies : 
1. insert(INTT,TT), voor het invoegen van tupels; INTT en TT 
zijn tabellen. 
2. delete(DTT), voor het verwijderen van de tupels in de tabel DTT. 
3. modify(MSE), voor het veranderen van tupels met behulp van de 
M(utatie) SE 


Voorafgaand aan elk van deze drie constructies kan eventueel 
gebruik worden gemaakt van de reeds bekende def constructie. 

Wij zullen nu elk van de onderhoudsopdrachten apart bespreken. 
Wij zullen daarbij steeds veronderstellen dat zkh een variabele is van 
het databasetype ziekenhuis (hoofdstuk 7) en dat zkh reeds een 
bepaalde waarde heeft. 


8.3.1 Invoegen (insert) 
Wij beginnen met een introductie via een voorbeeld. 


Voorbeeld 8.12 
Opdracht 


Voeg de volgende twee opnametupels, als weergegeven in onder- 
staande tabel, in. 
pnr opnr vnr indat uitdat snr 


15  datalogitis 26 820614 991231 36 
27 datalogitis 28 820614 991231 36 


Oplossing 1 
insert((((pnr,15),(opnr,datalogitis),(vnr,26), 
(indat ,820614), (uitdat ,991231),(snr,36)), 


((pnr,27),(opnr,datalogitis),(vnr,28), 
(indat ,820614), (uitdat ,991231),(snr,36) }}, zkh(opn)) 
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Oplossing 2 


def INOPN := (((pnr,15),(opnr,datalogitis),(vnr,26), 
(indat ,820614), (uitdat , 991231), (snr,36) }, 
((pnr,27),(opnr,datalogitis),(vnr,28), 
(indat ,820614), (uitdat,991231),(snr,36)) 
insert(INOPN, zkh(opn)) 


Bovenstaande invoegopdracht is gelijk aan de opdracht: 
zkh(opn) := zkh(opn) U INOPN o 


Hiervoor werd reeds de algemene vorm van de insert-opdracht gege- 

ven, namelijk insert(INTT,TT). Hierbij zijn TT en INTT tabelvaria- 

belen met hetzelfde domein. ; 
De insert-opdracht is gelijk aan de opdracht: 


SL :2 PT VINIT, 


Of een insert-opdracht uitvoerbaar is, hangt af van het feit of 
TT U INTT een tabel is, die niet strijdig is met het gegeven data- 
basetype. 


8.3.2 Verwijderen (delete) 
Ook hier beginnen wij weer met een voorbeeld. 


Voorbeeld 8.13 
Opdracht 


Verwijder de patiëntbehandelingstupels, die betrekking hebben op 
de patiënt met patiëntnummer 82 en op een behandelingsdatum in 
1980. 


Oplossing 1 
delete(it | t € zkh(pb) At(pnr) = 82 A 
800101 s t(dat) s 801231)) 


Oplossing 2 (met deflist) 
def DTT :- it |t € zkh(pb) At(pnr) = 82 A 
800101 s t(dat) < 801231) 
delete(DTT). 
Het resultaat van bovenstaande verwijder-opdracht is gelijk aan het 
resultaat van de opdracht: 
zkh(pb) := zkh(pb) > DTT D 
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In het algemeen heeft de verwijderopdracht de vorm: 
delete({t It ETT AP(t))), waarbij 
TT een tabelvariabele is, en 
P een predikaat over de tupels van TT. 
De delete-opdracht heeft hetzelfde resultaat als de opdracht : 
TT := TT Ü (tnT't/6 ta) 
Over de uitvoerbaarheid van een delete-opdracht moet, evenals bij 
de insert-opdracht, worden opgemerkt, dat deze afhankelijk is van 


het feit of de nieuwe waarde van TT een tabel is, die niet strijdig is 
met het gegeven databasetype. 


8.3.3 Veranderen (modify) 
Eerst weer een voorbeeld. 


Voorbeeld 8.14 
Opdracht 


Verander in het opnametupel met patiëntnummer 15 en indat 820614 
de waarde van uitdat in 820625. 


Oplossing 1 
modify({(t, ((uitdat ,820625))) | t € zkh(opn) A 
t(pnr) = 15 A 
t(indat) = 820614 }) 


Oplossing 2 
def MTT := it |t € zkh(opn) A t(pnr) = 15 A 
t(indat) = 820614) 
modifv(1(t, ((uitdat ,820625))) | t € MTT )). 
Het resultaat van bovenstaande modify-opdracht is gelijk aan het 
resultaat van de volgende opdracht: 
zkh(opn) := (zkh(opn) > MTT) U 


(tÍ dom (t) N (uitdat) U {(uitdat, 820625) } | 


t € MTT} We 


Bovenstaand voorbeeld is op twee manieren uitbreidbaar: 
— de verandering van de waarde van een attribuut is afhankelijk 
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van de bestaande waarde, bijvoorbeeld: tarief wordt 1,5 maal zo 
groot ; 

- meer dan een attribuut moet een verandering ondergaan, bijvoor- 
beeld adres ën woonplaats van een patiënt. 


Van beide uitbreidingen volgt nu een voorbeeld. 


Voorbeeld 8.15 
Opdracht 


Verander adres, woonplaats van specialist 12 in dalweg 18, geldrop 
en verander zijn afdelingsnummer in 7. 


Oplossing 
modifv(((t, ((sadr,dalweg 18),(swpl,geldrop),(spanr,7) } | 
t € zkh(sp) A t(snr) = 12)) | o 


Voorbeeld 8.16 
Opdracht 


Verminder van elke specialist met een aantal bedden > 0, dit aantal 
met 1. 


Oplossing : 
modify({(t,{(ab,t(ab) - 1))) It € zkh(sp) A t(ab) > 0}) 


Na het bovenstaande kunnen wij nu overgaan op de algemene vorm 
van een modify-opdracht. Deze is: 


modify(((t,mf(t) It € TT AP(t))), 


waarbij mf(t) een zogeheten modificatiefunctie op t is. Het domein 
van deze functie is de verzameling MA van alle te veranderen attri- 
buten en voor elk element ma van MA geldt dat mf(t)(ma) een uit- 
drukking is in t. (Deze uitdrukking kan ook een constante zijn, 
zoals in de voorbeelden 8.14 en 8.15.) 


Uit het voorgaande is eenvoudig onderstaand tabelletje af te leiden. 


voorbeeld modificatiefunetie 
8.14 ((uitdat , 820625) } | 
8.15 ((sadr,dalweg 18),(swpl,geldrop),(spanr,7)) 


8.16 ((ab,t(ab)-1)) 
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Het resultaat van een modify-opdracht is gelijk aan het resultaat van 
de volgende opdracht: 


TT := (TT x MTT) U 
(t/aom(t) ~ MA U {(ma,mf(t)(ma)) | ma € MA} I- 
t € MTT}, 


waarbij MTT = {t |t ETT A P(t)} 
mf(t): de modificatiefunctie op t 
MA: het domein van mf(t). 


Over de uitvoerbaarheid van een modify-opdracht geldt dezelfde 
opmerking als over de uitvoerbaarheid van een insert- en van een 
delete-opdracht. 


8.4 TRANSFORMATIE NAAR EEN VRAAGTAAL 


Zoals reeds in de eerste paragraaf van dit hoofdstuk werd vermeld, 
zullen wij nu enkele vragen en onderhoudsopdrachten beantwoorden 
en oplossen met behulp van de vraagtaal SQL. Men beschouwe dit 
als een voorbeeld van transformatie naar een bestaande vraagtaal. 
Uiteraard kan men een soortgelijke transformatie (trachten te) 
ondernemen met elke andere vraagtaal. De keus moet in dit opzicht 
verder aan de lezer zelf worden overgelaten, aangezien ter plaatse 
beschikbare faciliteiten een overheersende rol kunnen spelen. 

Voor de behandeling van de taal SQL zij verwezen naar DATE 
(hst. 7 en 9) en/of naar een SQL-user manual. 


Wij zullen nu (trachten) verschillende vragen van $ 8.2 in SQL 

weer (te) geven, en deze weergave waar nodig van commentaar 
voorzien. Voor de eenvoud van vergelijking zullen wij in deze para- 
graaf voor overeenkomstige voorbeelden dezelfde nummering aanhou- 
den plus de toevoeging S. Dus voorbeeld 8.18 is het SQL-equivalent 
van voorbeeld 8.1. 


Voorbeeld 8.1S 
Vraag 


Geef naam, adres en woonplaats van de specialisten, die tot afdeling 
9 behoren en over meer dan twee bedden kunnen beschikken. 


Antwoord 
SELECT SNM,SADR,SWPL 
FROM SP 


WHERE SPANR = 9 AND AB > 2 


109 


Commentaar 

Transformatie naar SQL 'recht-toe-recht-aan'; alleen wordt in SQL 
nooit de databasevariabele genoemd. Dus niet FROM ZKH.SP, maar 
alleen FROM SP. 


Voorbeeld 8.2S 


Vraag 


Geef naam, adres en woonplaats van de specialisten, die de behande- 
ling met code KNO6 hebben verricht. 


Antwoord 
SELECT SNM,SADR,SWPL 
FROM SP 
WHERE ( SNR IN 
Ë SELECT SNR 
FROM PB 
WHERE BCD = ''KNOG' 
Commentaar 


Het stuk A is het equivalent van "3u € zkh(pb)[u(snr) = t(snr) A 
u(bed) = KNO6]", hetgeen overigens zelf equivalent is met 

Tt(snr) € {u(snr) | u € zkh(pb) m(bed) = KNO6", en dit laatste is 
eigenlijk letterlijk de weergave sub A. In SQL kan verder de exis- 
tentiële quantor worden gerepresenteerd met behulp van de 
EXISTS-clausule. Het antwoord op de vraag van dit voorbeeld wordt ` 
dan 


SELECT SNM,SADR,SWPL 


FROM SP 
WHERE EXISTS 
(SELECT x 
FROM PB 
WHERE SNR = SP.SNR AND BCD = "KNO6") E 


Voorbeeld 8.3S 
Vraag 


Geef naam, adres en woonplaats van de patiënten die in 1980 werden 
opgenomen voor systologitis of infologitis. 


Antwoord 


SELECT PNM,PADR,PWPL 
FROM P 
WHERE PNR IN 
SELECT PNR 
FROM OPN 


WHERE OPNR IN < "SYSTOLOGITIS","INFOLOGITIS" > 
o 
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Voorbeeld 8. US 
Vraag 


Geef naam, adres en woonplaats van de patiënten die in 1980 werden 
opgenomen voor systologitis en voor infologitis. 


Antwoord 
SELECT PNM,PADR,PWPL 
FROM P 


WHERE < "SYSTOLOGITIS',"INFOLOGITIS" > IN 
SELECT OPNR 
p | FROM OPN 
WHERE PNR =P.PNR AND 
800101 < INDAT < 801231. 


Commentaar 
Ten overvloede zij opgemerkt, dat B de verzameling is van alle 
opnameredenen in 1980 van de 'aan de beurt zijnde' patiënt. o 


Nu komen wij aan het gebruik van de functies #, sum, max, min, 
average. De (min of meer) equivalenten hiervan in SQL zijn de zoge- 
heten built-in functions COUNT, SUM, MAX, MIN, AVG. 


Voorbeeld 8.5S 
Vraag 


Geef naam, adres en woonplaats van elke specialist, die in 1980 meer 
dan 10 maal de behandeling KNOT heeft verricht en die voor deze 
behandeling in 1980 gemiddeld meer dan een half uur nodig had. 


Antwoord 
SELECT SNM,SADR,SWPL 
FROM SP 
WHERE (SELECT COUNT(*) 
ne FROM PB 
WHERE SNR = SP.SNR AND 
800101 < DAT < 801231 AND 
BCD = "KNO7") > 10 
AND i 
(SELECT AVG(DUUR) 
FROM PB 
WHERE SNR = SP.SNR AND 
| 800101 < DAT < 801231 AND 
BCD = 'KNOT') > 30 
Commentaar 


— COUNT(*) betekent: tel aantal tupels van de tabel onder FROM. 
— In SQL betekent AVG(DUUR) het gemiddelde over alle voorko- 
mende waarden van dit attribuut, waarbij meermalen voorkomende 


111 


waarden ook meermalen meetellen. Wil men meermalen voorkomende 
waarden maar éénmaal meetellen, dan moet AVG(UNIQUE DUUR) 
worden gebruikt. o 


Voor een SQL-equivalent van voorbeeld 8.6 zie verderop voorbeeld 
8. 8S. 


Voorbeeld 8.7S 
Vraag 


Geef naam, adres en woonplaats van de specialisten, die in 1980 min- 
stens éénmaal een behandeling B13 hebben uitgevoerd, zodanig dat 
deze behandeling langer duurde dan enige behandeling B13 in 1979 
door welke specialist ook. 


Waar in het antwoord van voorbeeld 8.7 sprake was van splitsing met 
behulp van de def-clausule, kan dit in SQL ook (tenminste wat 
betreft tabellen) en wel met behulp van de zogeheten DEFINE VIEW- 
clausule. 


Antwoord 


DEFINE VIEW H AS 
SELECT UNIQUE SNR,DUUR 
FROM PB 
WHERE 800101 s DAT s 801231 AND 
BCD = "B13". 


SELECT SNM,SADR,SWPL 
FROM SP 
WHERE SNR IN 
e SELECT SNR 
FROM H 
WHERE DUUR > 
SELECT MAX(DUUR) 


FROM PB 
WHERE 790101 < DAT < 791231 AND 
BCD = "B13". D 


Voorbeeld 8.8S 
Vraag 


Geef van elke specialist, die in 1980 meer dan 10 maal de behande- 
ing KNO7 heeft verricht: naam, adres, woonplaats, het aantal malen 
dat hij deze behandeling heeft verricht in 1980 en de maximale en 
gemiddelde duur van dit aantal. 
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Antwoord 


DEFINE VIEW SPBEH(SNR,AANTAL,MAXDUUR,GEMDUUR) AS 
SELECT SNR,COUNT(*),MAX(DUUR),AVG(DUUR) 
FROM PB 
WHERE 800101 < DAT < 801231 AND BCD = "KNO7" 
GROUP BY SNR 
HAVING COUNT(*) > 10 


SELECT SNM,SADR,SWPL,AANTAL,MAXDUUR,GEMDUUR 
FROM SP,SPBEH 
WHERE S.SNR = SPBEH.SNR 


In SQL kan het antwoord op deze vraag niet anders dan in 'opge- 
splitste' vorm, dus met een DEFINE-gedeelte, worden gegeven. Een 
antwoord, analoog aan dat van voorbeeld 8.6, is dus niet mogelijk in 
SQL. Dit is te wijten aan het feit, dat de parameters (variabelen) 
van de built-in functions niet bij de functie-aanroep zelf vermeld 
staan, maar ‘daarbuiten her en der verspreid liggen' en daardoor 
moeilijk of in het geheel niet als zodanig herkenbaar zijn. Deze 
‘eigenschap! van de built-in functions kan tot vrij ingewikkelde ant- 
woorden leiden. Stel bijvoorbeeld dat bovenstaande vraag vervangen 
wordt door de volgende: 

Geef van elke specialist: naam, adres, woonplaats en het aantal 
malen, dat hij in 1980 de behandeling KNO7 heeft verricht. 

Beantwoording in het verzamelingsmodel kan eenvoudig geschie- 
den door uit het antwoord van voorbeeld 8.6 enkele regels weg te 
laten, zodat men krijgt: 


get ({(t /isnm ‚sadr‚swpl}, 
#({u l u € zkh(pb) Au(snr) =t(snr) A 
800101 s u(dat) s 801231 A 
u(bed) = KNOT} It € zkh(sp) }). 


Een antwoord in SQL, op analoge wijze met weglating van 'overeen- 
komstige! gedeelten, zou leiden tot: 


DEFINE VIEW SPBEH(SNR,AANTAL) AS 
SELECT SNR,COUNT (*) 
FROM PB 
WHERE 800101 < DAT < 801231 AND BCD = ''KNOT' 
GROUP BY SNR 


SELECT SNM,SADR,SWPL,AANTAL 
FROM SP,SPBEH 
WHERE S.SNR = SPBEH.SNR. 


Met dit antwoord zouden dan echter de specialisten, die nog geen 
enkele behandeling hebben verricht, onvermeld blijven. 
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Een juist antwoord in SQL kan worden verkregen door een nieuwe 
tabel (object) of (iets eenvoudiger) een nieuw veld (attribuut) te 
'creġren'. Wij geven hier het antwoord met behulp van een nieuw 

veld. 


EXPAND TABLE SP 
ADD AANTAL INTEGER 


UPDATE SP 
SET AANTAL = 0 
UPDATE SP 
SET AANTAL = 
(SELECT COUNT (*) 
FROM PB 
WHERE SNR = SP.SNR AND 800101 < DAT < 801231 
AND BCD = "KNOT") 


WHERE SNR IN 
(SELECT SNR ` 
FROM PB) 


SELECT SNM,SADR,SWPL,AANTAL 
from SP. 


Met de voorbeelden 8.9, 8.10 en 8.11 bevinden wij ons op het gebied 
van de ssr's en dus in het geval van een genormaliseerd database- 
type, op het gebied van de externe sleutels. Dit begrip is (bij mijn 
weten) onbekend in SQL. Om te demonstreren hoe men hiermee in 
SQL 'terecht' komt, moge een behandeling van voorbeeld 8.11 vol- 
staan. 


Voorbeeld 8.11S 
Vraag 


Geef van elke behandeling die in mei 1980 werd verricht door een 
specialist van de afdeling dermatologie: behandelcode en -soort , 
patiëntnummer en -naam, datum, specialistnummer en -naam. 


Antwoord 


SELECT BCD,BSRT,P.PNR,PNM,DAT,SP.SNR,SNM 
FROM PB,P,SP,BEH 
WHERE 800501 < DAT < 800531 AND 
PB.PNR = P.PNR AND 
PB.SNR = SP.SNR AND PB. BCD = BEH.BCD AND 


SP. SPANR IN 
SELECT ANR 
FROM AFD 


WHERE ANM = "DERMATOLOGIE". a 
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Wij zullen nu enkele onderhoudsopdrachten van $ 8.3 in SQL weer- 
geven. 

Voorbeeld 8.12S 

Opdracht 


Voeg de volgende twee opnametupels, als weergegeven in onder- 
staande tabel, in. 


pnr opnr vnr indat uitdat snr 


15 datalogitis 26 820614 991231 36 
27  datalogitis 28 820614 991231 36 


Oplossing 
INSERT INTO OPN(PNR,OPNR,VNR,INDAT,UITDAT,SNR): 
< 15,"DATALOGITIS",26,820614,991231,36 > 
INSERT INTO OPN(PNR,OPNR,VNR,INDAT,UITDAT,SNR): 
< 27, 'DATALOGITIS',28,820614,991231,36 >. 


Commentaar 

In SQL is invoeging alleen mogelijk op tupelniveau. Er zijn dan ook 
twee INSERT-opdrachten nodig. 

(Pseudo-invoeging, door ‘overname! uit andere tabellen, kan wel op 
tabelniveau.) o 


Voorbeeld 8.13S 
Opdracht 


Verwijder de patiëntbehandelingstupels die betrekking hebben op de 
patiënt met patiëntnummer 82 en op een behandelingsdatum in 1980. 


Oplossing 
DELETE PB 
WHERE PNR = 82 AND 800101 < DAT < 801231. o 


Van de veranderingsopdrachten zullen wij alleen voorbeeld 8.15 in 
SQL behandelen. 

Voorbeeld 8.15S 

Opdracht 


Verander adres, woonplaats van specialist 12 in dalweg 18, geldrop 
en verander zijn afdelingsnummer in 7. 
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Oplossing 
UPDATE SP 
SET SADR = "DALWEG 18", 
SWPL = "GELDROP", 
SPANR = 7 
WHERE SNR = 12. o 


Samenvattend kan het volgende worden opgemerkt over de transfor- 

matie naar SQL: 

- mits geen built-in functions nodig zijn, geeft de transformatie 
weinig problemen; 

- als built-in functions wel nodig zijn, kan het erg lastig worden de 
juiste transformatie tot stand te brengen; 

- in eerste instantie is niet de taal het belangrijkste, maar een goe- 
de verzamelingsanalyse van het gestelde probleem. 


OPGAVEN 


Alle opgaven hebben betrekking op een ziekenhuis-database volgens 
de definitie van hoofdstuk 7. 

Voor de opgaven 8.1-8.30: antwoord volgens het verzamelingsmodel 
(en naar believen in één of meer vraagtalen). 


8.1 Geef alle gegevens van de patiënten die in Eindhoven wonen. 


Geef nummer en naam van de specialisten, die tussen 
1 november 1978 en 1 februari 1979 verantwoordelijk zijn 
geweest voor een opname. 


8.3 Geef alle gegevens van de patiënten die tussen 1 november 1978 
en 1 februari 1979 werden opgenomen in afdeling 12. 


8.4 Geef van elke afdeling: nummer, naam, aantal verpleegkundigen 
en aantal specialisten. 


8.5 Geef nummer en naam van elke afdeling waarvoor geldt dat het 
totale aantal voor specialisten beschikbare bedden minder dan 
20% van het totale aantal beschikbare bedden bedraagt. 


8.6 Geef de gegevens van de specialisten, die in januari 1979 ver- 
antwoordelijk zijn geweest voor de opnamen in afdeling 5. 


8.7 Geef nummer en naam van de afdelingen, waarvan hoofdspecia- 
list en hoofdverpleegkundige niet in dezelfde plaats wonen. 


8.8 Geef nummer en naam van de patiënten die zowel medicijn M12A 
als medicijn M12C hebben gebruikt. 
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Geef van elke afdeling met meer dan twee verpleegruimten: 
nummer, naam en totaal aantal beschikbare bedden. 


Geef nummer en naam van de specialisten, die aan patiënten 
die werden opgenomen voor 'helioritis' een medicijn van de 
soort MSX18 hebben voorgeschreven. 


Geef nummer en naam van de patiënten die de behandelingen 
B26, B13, B26, B30 in deze volgorde hebben ondergaan. 


Geef nummer en naam van de specialisten, die minstens alle 
behandelingen hebben verricht, die ook door specialist 12 zijn 
verricht. 


Geef nummer en naam van elke specialist, die minstens twee 
verschillende soorten behandelingen heeft verricht (let wel: 
soort is niet gelijk aan code). 


Geef nummer en naam van elke afdeling, waaraan minstens 
twee specialisten verbonden zijn die in juni 1979 de behande- 
ling B09 hebben verricht. 


Geef van elke specialist, die behandelingen van soort BS2X 
heeft verricht: nummer, naam, aantal malen dat hij deze soort 
behandeling heeft verricht, maximale duur, gemiddelde duur. 


Geef nummer en naam van elke afdeling, waarin in de week 
van 11 tot en met 17 februari 1979 geen patiënten uit Geldrop 
werden opgenomen. 


Geef nummer en naam van elke patiënt, die in 1978 niet in twee 
of meer verschillende afdelingen heeft gelegen. 


Geef alle gegevens van de patiënten, die werden behandeld 
door (minstens) een specialist, die een behandeling verrichtte 
op (minstens) een patiënt, die werd behandeld door (minstens) 
een specialist van afdeling 9. 


Geef nummer en naam van de specialisten van afdeling 15, die 
in maart 1979 een patiënt hebben behandeld in een behandel- 
ruimte, waarin in februari 1979 een patiënt een behandeling 
heeft ondergaan van de soort BS15A7. 


Geef nummer en naam van de patiënten, die werden opgenomen 
in afdeling 17 en (tijdens dezelfde opname), na minstens twee- 
maal verstrekking van minstens vijf stuks van het medicijn 
MX13 een behandeling van de soort BS07 hebben ondergaan. 


Geef nummer en naam van de patiënten die in januari 1979 
werden opgenomen in een afdeling waarin in december 1978 
geen patiënten werden opgenomen, waarvoor de opnamereden 
informaritis' was en die in december 1978 werden behandeld 
door een specialist, die in de periode januari tot en met 
november 1978 geen behandeling had verricht op een patiënt, 
die in diezelfde periode voor 'informaritis' werd opgenomen. 
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Geef van de patiënt met nummer 26: de opnamereden van elke 
opname in 1980. 


Geef nummer en naam van de specialisten, die meer dan vijf 
maal de behandeling met code KNO6 hebben verricht. 


Geef het aantal keren dat in de periode 15 september 1979 tot 
16 januari 1980 het medicijn validon werd voorgeschreven. 


Geef naam, adres en woonplaats van de specialisten, die sinds 
begin 1980 geen behandeling met code KNO6 hebben verricht. 


Geef naam, adres en woonplaats van de specialisten, die sinds 
begin 1980 wel de behandelingen met code KNO7, KNOS8 en 
KNO9 hebben verricht, maar niet KNO6. 


Geef van elke opname in de periode 16 tot en met 23 januari 
1980 in de afdeling verloskunde: nummer en naam van de 
patiënt, opnamereden en nummer van verpleegruimte. 


Geef naam, adres en woonplaats van elke patiënt, die in 
februari 1981 werd opgenomen voor informaritis en die tijdens 
deze opname tweemaal vijf dagen het medicijn M15 kreeg voor- 
geschreven. 


Geef van elke patiënt met bloedgroep AB: naam, adres en 
woonplaats en aantal dagen dat deze patiënt in maart 1980 het 
medicijn M12 heeft moeten gebruiken. 


Geef naam, adres en woonplaats van de specialisten, die in 
december 1980 verantwoordelijk zijn geweest voor de opname 
van een patiënt uit Eindhoven en die aan deze zelfde patiënt 
minstens vijf maal een medicijn van de soort S05 hebben voor- 
geschreven. 


Voor de opgaven 8.31, 8.32 en 8.33: Gegeven is een vraag en een 
antwoord. Ga na of het antwoord juist is. Zo nee, geef dan weer 
welke vraag door het gegeven antwoord wèl wordt beantwoord èn 
geef het correcte antwoord op de gegeven vraag. 


8. 31 


Vraag 

Geef nummer en naam van elke patiënt die in de periode 11-18 
april 1980 een behandeling onderging in een behandelruimte, 
waarin in de tien dagen, voorafgaande aan deze behandeling 
een patiënt werd behandeld voor de behandeling met code BX. 


Antwoord 


get ({t/{pnr‚pnm} | tEzkh(p) 13uEzkh(pb) [u(pnr) =t(pnr) A 
en 800411 < u(dat) < 800418 A 

ivezkh(pb) Iv(pnr) =u(pnr) A 

800401 < v(dat) < 800411 Av(bed) -BX11)). 
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8.32 Vraag 
Geef nummer en naam van elke patiënt, die in de periode 11-18 
april 1980 een behandeling onderging in een behandelruimte, 
waarin in de tien dagen, voorafgaande aan deze behandeling, 
geen patiënt werd behandeld voor een behandeling van de 
soort SX. (Let wel: soort is niet gelijk aan code.) 


Antwoord | 


get (it /ipnr,pnm) | t € zkh(p) A 3uEzkh(pb) 
[u(pnr) =t(pnr) A 800411 su(dat) < 800418 A 
TI(avezkh(pb) 
[u(pnr) = v(pnr) A 800401 sv(dat) < 800411 A 
V(bed) = SX])]}). 


8.33 Vraag 
Geef nummer, naam en woonplaats van de patiënten, die geen 
behandeling van soort BS13 hebben ondergaan. 


Antwoord 


get ({t/{pnr‚pnm‚pwpl} l t € zkh(p) A 
vuEzkh(pb)[u(pnr) £ t(pnr) A 
(beh*(u) ext zkh(beh))(bsrt) # BS13)). 


De onderhoudsopdrachten in de nu volgende opgaven uitvoeren vol- 
gens het verzamelingsmodel (en naar believen in één of meer vraag- 
talen). 


8.34 Voeg in de volgende pb-tupels, als weergegeven in onder- 
staande tabel. 


pnr bed snr indat dat duur behr 


15 DL11 13 820614 820616 250  BRIL 
15 DL11 13 820614 820617 120 BR10 
27 DLM 13 82014 830616 430 BRIL 


8.35 Verander de duur van de behandeling DL11 op patiënt 15 op 
16 juni 1982 in 2 uur. 


8.36 Verlaag van elke behandeling van soort SDL, die in 1980 
meer dan vijftig maal werd verricht, het tarief met 105. 


8.37 Verwijder het patiëntbehandelingstupel betreffende behande- 
ling DL11 op patiënt 15 op 16 juni 1982. 


8.38 Verwijder het specialistentupel van specialist 8 en alle patiënt- 
behandeling- en medicijnverstrekkingtupels, waarin deze spe- 
cialist voorkomt. 


DEEL III 
HET NETWERKMODEL 


9 LOGISCHE STRUCTUUR IN HET 
NETWERKMODEL 


9.1 INLEIDING 


In het eerste hoofdstuk werd er, met name in $ 1.4, reeds op gewe- 
zen, dat duidelijk onderscheid dient te worden gemaakt tussen de 
verschillende gegevensstructuren in de verschillende fasen van een 
database-ontwerp. Een en ander werd schematisch weergegeven in 
figuur 1.5. 

Bij deze figuur werd er met nadruk op gewezen, dat de opslag- 
structuur niet alleen afhankelijk is van de (reeds vooraf bepaal- 
de) logische structuur, maar ook van de eisen betreffende de 
toegang tot de gegevens. Deze toegangseisen kunnen gemakkelijk de 
logische structuur 'verstoren'. Zo kan het bijvoorbeeld voorkomen, 
dat genormaliseerde structuren minder wenselijk zijn in de opslag- 
fase. 

Om te weten in hoeverre de logische structuur door toegangs- 
eisen wordt verstoord, dient men uiteraard logische structuur en 
opslagstructuur wel goed van elkaar te onderscheiden. Dit onder- 
scheid nu (en natuurlijk daarbij ook nog het onderscheid met de 
fysieke structuur) is in de beschikbare database management syste- 
men niet eenvoudig en soms zelfs moeilijk of helemaal niet aan te 
houden. 

Wij zullen voor een bepaalde klasse van database management 
systemen laten zien hoe de logische structuur daarin is af te beel- 
den en tevens hoe behandeling van queries en onderhoud in deze 
systemen kan plaatsvinden. Daarbij zullen diverse 'implementatieza- 
ken! betreffende opslag van gegevens ook aan de orde (moeten) 
komen. 

Bedoelde klasse van database management systemen is die welke 
gebaseerd is op het zogeheten netwerkmodel oftewel DBTG-model. 
Er zijn twee belangrijke redenen waarom in dit boek voor deze klas- 
se is gekozen. 

1. Een groot aantal van de beschikbare DBMS'en behoort tot deze 
klasse. 

2. Het netwerkmodel leent zich goed om te demonstreren hoe een 
duidelijke logische strcutuur kan worden 'geimplementeerd'. 
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Het netwerkmodel werd ontwikkeld door de zogeheten Data Base Task 
Group (daarvandaan DBTG-model) van het CODASYL Programming 
Language Committee (daarvandaan ook de benaming CODASYL-model). 
De benaming netwerkmodel zal verderop worden verklaard. Voor uit- 
gebreide informatie over dit model zij verwezen naar (OLLE), 
(CODASYL 71), (DOROVK) en (DORSTR). 

In april 1971 verscheen een rapport van de DBTG, met o.a. een 
voorstel voor een DDL (Data Description Language) en een DML 
(Data Manipulation Language). Er zijn daarna nog verschillende 
revisies verschenen (o.a. in 1973, 1976 en 1978), die echter het 
wezenlijke van de 1971-voorstellen onaangetast hebben gelaten. 

In het DBTG-model worden het logische en de daaronder liggende 
niveaus niet altijd duidelijk gescheiden. Bij de behandeling van de 
diverse onderdelen zal hierop nader worden ingegaan. 


De voor ons doel van belang zijnde begrippen van het DBTG-model 
zullen worden toegelicht met behulp van een zogeheten DBTG-schema. 
Dit schema wordt in de volgende paragraaf gegeven en is het DBTG- 
'equivalent' van de ziekenhuis-database van hoofdstuk 7. 

Aangezien het de bedoeling is na te gaan hoe de logische struc- 
tuur kan worden afgebeeld in een systeem volgens het DBT G-model, 
zullen vele van de hierbij niet ter zake doende DBTG-begrippen 
onbesproken blijven. Voor deze begrippen zij verwezen naar de 
bovengenoemde literatuur. 


In dit deel over het netwerkmodel zullen wij gebruik maken van de 
DBMS-20 van DEC. Onder deze DBMS is op de TH Eindhoven een 
database (met ongeveer 100.000 recordoccurrences) volgens de 
structuur van hoofdstuk 7 geïmplementeerd ten behoeve van onder- 
wijs en onderzoek. 


9.2 DBTG-SCHEMA VAN EEN ZIEKENHUIS-DATABASE 


Opmerkingen 
- Zoals in het voorgaande reeds werd opgemerkt, is het de bedoe- 
ling onderstaand schema in de loop van de volgende paragrafen 

en hoofdstukken te 'ontvouwen'. 

- Regels beginnend met een sterretje, zoals r. 10-12, 25-27, enz. 
zijn zogeheten commentaarregels. Deze behoren niet tot het sche- 
ma. | 

- Het schema eindigt eigenlijk op r. 291. Daarna volgen nog twee 
subschema's. 
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20 


25 


30 


35 


40 


45 


SCHEMA NAME IS HOSPITAL PRIVACY LOCK FOR ADMINISTRATION IS 


AREA NAME IS STATISCH-AREA 
PRIVACY LOCK FOR PROTECTED RETRIEVAL IS RETRV. 


AREA NAME IS PATIENT-AREA 


PRIVACY LOCK FOR PROTECTED RETRIEVAL IS RETRV. 


AREA NAME IS OPNAME-AREA 


PRIVACY LOCK FOR PROTECTED RETRIEVAL IS RETRV, 


AREA NAME IS MEDVER-AREA 


PRIVACY LOCK FOR PROTECTED RETRIEVAL IS RETRV. 


* 
* record beschrijving van patient 
* 


RECORD NAME IS P 


LOCATION MODE IS CALC USING P-NR 
DUPLICATES ARE NOT ALLOWED 

WITHIN PATIENT-AREA. 

02 P-NR PIC 9(5). 
02 P-NM PIC X(20). 
02 P-ADR PIC X(20). 
02 P-WPL PIC X(15). 
02 P-DAT PIC X(6). 
02 P-BLOED PIC X(2). 
02 P-RHES PIC X(1). 
02 P-MV PIC ZIL), 


* 
* record beschrijving van verpleegkundige 
* 


RECORD NAME IS VK 


LOCATION MODE IS VIA SYS-VK 
WITHIN STATISCH-AREA. 


02 VK-NR PIC 9(3). 
02 VK-NM PIC X(19). 
02 VK-ADR PIC X(18). 
02 VK-WPL PIC X(9). 
02 VK-AFD-NR PIC 9(2). 


* 
* record beschrijving van specialist 
* 


RECORD NAME IS SP 
LOCATION MODE IS CALC USING SP-NR 
DUPLICATES NOT ALLOWED 
WITHIN STATISCH-AREA. 


02 SP-NR PIC 9(2). 
02 SP-NM PIC X(19). 
02 SP-ADR PIC X(18). 
02 SP-WPL PIC X(9). 
02 SP-AFD-NR PIC 9(2). 
02 SP-AB PIC 9(2)-. 
02 SP-IND PIC: EK, 


VVJG. 
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50 * 
* record beschrijving van afdeling 
Ki 


RECORD NAME IS AFD 


LOCATION MODE IS VIA SYS-AFD 


55 WITHIN STATISCH-AREA. 
02 AFD-NR PLG 9443)w 
02 AFD-NM PIC X(20). 
02 AFD-VK-NR PIG SEA, 
02 AFD-SP-NR PIC 9(2). 
60 * 


* record beschrijving van verpleegruimte 
* 


RECORD NAME IS VPR 
LOCATION MODE IS VIA AFD-VPR 


65 WITHIN STATISCH-AREA, 
02 VPR-NR PIC AG, 
02 VPR-AFD-NR PIC 9(2). 
02 VPR-AB PIC:9(2): 


* 


70 * record beschrijving van opname 
* / 
RECORD NAME IS OPN 
LOCATION MODE IS VIA P-OPN 
WITHIN OPNAME-AREA. 


75 02 OPN-P-NR PIC 9(5)- 
02 OPN-R PIC X(40). 
02 OPN-VPR-NR PIC. 9(2): 
02 OPN-IN-DAT PIC 9(6). 
02 OPN-UIT-DAT PIC 9(6). 

80 02 OPN-SP-NR PIC 9(2). 


* 
* record beschrijving van behandeling 
* 


RECORD NAME IS BEH 
85 LOCATION MODE IS CALC USING BEH-CD 
DUPLICATES NOT ALLOWED 
WITHIN STATISCH-AREA, 


02 BEH-CD PIC 9(4). 
02 BEH-NM PIC X(50). 
90 02 BEH-SRT PIG 3, 


02 BEH-TAR PIC 9(3). 
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* 


* record beschrijving van patient behandeling 
* 
95 RECORD NAME IS PATBEH 
LOCATION MODE IS VIA OPN-PATBEH 
WITHIN OPNAME-AREA. 


02 PB-P-NR PIC 9(5). 
02 PB-BEH-CD PIC 9(4). 
100 02 PB-SP-NR PIC 97132). 
02 PB-DAT PIC-9(0)4 
02 PB-DUUR PIC: 9(3). 
02 PB-BEHR PIC X(4). 


* 


105 * recordbeschrijving van medicijn 
* 
RECORD NAME IS MED 
LOCATION MODE IS CALC USING MED-CD 
DUPLICATES NOT ALLOWED 


110 WITHIN STATISCH-AREA. 
02 MED -CD PIC X(6). 
02 MED-NM PIC X(20). 
02 MED-SRT PIC X(4). 


k. 
115 * record beschrijving van cummulatieve recepten 
* 


RECORD NAME IS MEDVER 


LOCATION MODE IS VIA P-MEDVER 
WITHIN MEDVER-AREA, 


120 02 MV-MED-CD PIC X(6). 
02 MV-P-NR FIC 915). 
02 MV-SP-NR PIC 9(2). 
02 MV-DATUM PIC 9(6). 
02 MV-DUUR PIC 9(2). 
125 02 MV-DAG PIC 9(1). 
02 MV-AANT PIC 9(1). 


SET NAME IS SYS-AFD 
MODE IS CHAIN 
ORDER IS SORTED 
130 DUPLICATES NOT ALLOWED 

OWNER IS SYSTEM 

MEMBER IS AFD 
MANDATORY AUTOMATIC 
ASCENDING KEY IS AFD-NR. 


135 SET NAME IS SYS-VK 
MODE IS CHAIN 
ORDER IS SORTED 
DUPLICATES NOT ALLOWED 

OWNER IS SYSTEM 

140 MEMBER IS VK 
MANDATORY AUTOMATIC 
ASCENDING KEY IS VK-NR. 
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SET NAME IS SYS-SP 
MODE IS CHAIN 
145 ORDER IS SORTED 
DUPLICATES NOT ALLOWED 
OWNER IS SYSTEM 


MEMBER IS SP 
MANDATORY AUTOMATIC 
150 ASCENDING KEY IS SP-NR. 


SET NAME IS SYS-P 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
OWNER IS SYSTEM 
155 MEMBER IS P 
MANDATORY AUTOMATIC. 


SET NAME IS SYS-MED 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
160 OWNER IS SYSTEM 
MEMBER IS MED 
MANDATORY AUTOMATIC. 


SET NAME IS SYS-BEH 
MODE IS CHAIN 
165 ORDER IS ALWAYS LAST 
OWNER IS SYSTEM 
MEMBER IS BEH 
MANDATORY AUTOMATIC, 


SET NAME IS AFD-VPR 
170 MODE IS CHAIN 
ORDER IS ALWAYS LAST 
OWNER IS AFD 
MEMBER IS VPR 
MANDATORY AUTOMATIC 
175 SET OCCURRENCE SELECTION THRU 
LOCATION MODE OF OWNER 
USING AFD-NR, 


SET NAME IS VPR-OPN 
MODE IS CHAIN 
180 ORDER IS SORTED 
OWNER IS VPR 
MEMBER IS OPN 
AUTOMATIC MANDATORX 
LINKED TO OWNER 
185 ASCENDING KEY IS OPN-IN-DAT 
DUPLICATES ARE LAST ALLOWED 
SET OCCURRENCE SELECTION THRU 
CURRENT OF SET. 
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SET NAME IS AFD-VK 
190 MODE IS CHAIN 
_ ORDER IS ALWAYS LAST 
OWNER IS AFD 
MEMBER IS VK 
MANDATORY AUTOMATIC 
195 SET OCCURRENCE SELECTION IS THRU 
LOCATION MODE OF OWNER 
USING AFD-NR, 


SET NAME IS AFD-SP 
MODE IS CHAIN 
200 ORDER IS ALWAYS LAST 
OWNER IS AFD 
MEMBER IS SP 
MANDATORY AUTOMATIC 
SET OCCURRENCE SELECTION IS THRU 
205 LOCATION MODE OF OWNER 
USING AFD-NR. 


SET NAME IS SP-OPN 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
210 OWNER IS SP 
MEMBER IS OPN 
AUTOMATIC MANDATORY 
LINKED TO OWNER 
i SET OCCURRENCE SELECTION IS THRU 
215 LOCATION MODE OF OWNER. 


SET NAME IS SP-PATBEH 
MODE IS CHAIN 
ORDER IS SORTED 
OWNER IS SP 
220 MEMBER IS PATBEH 
MANDATORY AUTOMATIC 
LINKED TO OWNER 
ASCENDING KEY IS PB-BEH-CD 
DUPLICATES ARE LAST ALLOWED 
225 SET OCCURRENCE SELECTION IS THRU 
— LOCATION MODE OF OWNER. 


SET NAME IS P-OPN 
MODE IS CHAIN 
ORDER IS SORTED 
230 OWNER IS P 
MEMBER IS OPN 
MANDATORY AUTOMATIC ` 
ASCENDING KEY IS OPN-SP-NR 
DUPLICATES ARE LAST ALLOWED 
235 SET OCCURRENCE SELECTION IS THRU 
LOCATION MODE OF OWNER. 
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SET NAME IS P-PATBEH 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
240 OWNER IS P 
MEMBER IS PATBEH 
MANDATORY AUTOMATIC 
SET OCCURRENCE SELECTION IS THRU 
LOCATION MODE OF OWNER. 


245 SET NAME IS OPN-PATBEH 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
OWNER IS OPN 
MEMBER IS PATBEH 
250 MANDATORY AUTOMATIC 
SET OCCURRENCE SELECTION IS THRU 
CURRENT OF SET, 


SET NAME IS P-MEDVER 
MODE IS CHAIN 
255 ORDER IS ALWAYS LAST 
OWNER IS P 
MEMBER IS MEDVER 
MANDATORY AUTOMATIC 
SET OCCURRENCE SELECTION IS THRU 
260 LOCATION MODE OF OWNER. 


SET NAME IS BEH-PATBEH 
MODE IS CHAIN 
ORDER IS ALWAYS LAST 
OWNER IS BEH 
265 MEMBER IS PATBEH 
MANDATORY AUTOMATIC 
LINKED TO OWNER 
SET OCCURRENCE SELECTION IS THRU 
LOCATION MODE OF OWNER. 


270 SET NAME IS SP-MEDVER 
MODE IS CHAIN 
ORDER IS SORTED 


OWNER IS SP 
MEMBER IS MEDVER 
275 MANDATORY AUTOMATIC 


LINKED TO OWNER 
ASCENDING KEY IS MV-MED-CD 
DUPLICATES ARE LAST ALLOWED 
SET OCCURRENCE SELECTION IS THRU 
280 LOCATION MODE OF OWNER. 
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285 


290 


295 


300 


305 


310 


315 


SET NAME IS MED-MEDVER 
MODE IS CHAIN 
ORDER IS SORTED 
OWNER IS MED 
MEMBER IS MEDVER 
MANDATORY AUTOMATIC 
LINKED TO OWNER 
ASCENDING KEY IS MV-P-NR 
DUPLICATES ARE LAST ALLOWED 
SET OCCURRENCE SELECTION IS THRU 
LOCATION MODE OF OWNER. 


SUB-SCHEMA NAME IS HOSPIT-SUBO1 
PRIVACY LOCK GVJV. 
AREA SECTION, 
COPY ALL AREAS, 
RECORD SECTION. 
COPY ALL RECORDS, 
SET SECTION. 
COPY ALL SETS. 


SUB-SCHEMA NAME IS HOSPIT-PRAKT 
PRIVACY LOCK IS PRAKT. 
AREA SECTION. 
COPY PATIENT-AREA,OPNAME-AREA, 
RECORD SECTION, 


01 P. 
02 P-NR. 
01 OPN. 
02 OPN-P-NR. 
02 OPN-R. 
oa OPN-IN-DAT. 
02 OPN-UIT-DAT. 


SET SECTION. 
COPY P-OPN. 


END-SCHEMA. 
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9.3 RECORDTYPE EN SETTYPE 


Een DDL, volgens het DBTG-model, werkt met drie basisbegrippen: 
area, recordtype en settype. 


Een area is een deel van het (achtergrond)geheugen dat beschikbaar 
is voor de database. Dit begrip is van geen belang voor de weergave 
van de betekenis van de gegevens, dus voor de logische structuur, 
maar wel voor de realisatie van de toegangseisen, dus voor de 
opslagstructuur. Met geschikt gekozen area's is het mogelijk effi- 
ciënt onderhoud en gebruik van de gegevens te bewerkstelligen. In 
ons schema (r. 2-9) is sprake van vier area's: STATISCH-AREA, 
PATIENT-AREA, OPNAME-AREA en MEDVER-AREA. 


Een record, of ook dikwijls recordtype, is eigenlijk een bijzonder 
geval van het in hoofdstuk 3 genoemde tupeltype. Het bijzondere zit 
in het feit, dat niet of nauwelijks mogelijkheden aanwezig zijn om 
tupel- en tabelconstraints te definiëren. Alleen via de zogeheten 
LOCATION MODE IS CALC (zie verderop) is het mogelijk op een im- 
pliciete wijze aan te geven dat een groep identifiers uniek identifice- 
rend is. Evenals voor het recordtype van Pascal geldt dus ook voor 
het DBTG-recordtype dat het een bijzonder geval is van een tupel- 
type. 

De tien objecten van hoofdstuk 7 vinden wij in het schema van 
$ 9.2 terug in evenzovele recordbeschrijvingen, beginnend met 
"RECORD NAME IS". De LOCATION MODE-clausule zal, zoals 
gezegd, verderop worden behandeld. 

WITHIN PATIENT-AREA (r. 16) betekent, dat de recordoccur- 
rences van het desbetreffende recordtype moeten worden opgeslagen 
in de area PATIENT-AREA. 

Bij de beschrijving van de data-items (attributen) van een 
recordtype wordt de COBOL-aanpak gevolgd met level numbers (02 
en eventueel ook hogere) en PIC(TURE)-clausules. Zo'n PIC- 
clausule is in feite een type-definitie voor een attribuut. Zo is (r.17) 


"02 P-NR PIC 9(5)' 
het netwerkequivalent van 

TP-NR : 10...99999 H 
en (r.18) 

"02 P-NM PIC X(20)" 
het netwerkequivalent van 

"P-NM : charstring 20". 
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Opmerking 

De attribuutnamen van hoofdstuk 7 konden niet letterlijk worden 
overgenomen, omdat in het onderhavige DBMS geëist wordt dat elke 
attribuutnaam uniek is binnen het totale schema. o 


Met een settype wordt beoogd een verband tussen twee recordtypen 
vast te leggen en wel op de volgende wijze. Een van deze twee 
recordtypen is (binnen het gegeven settype) het zogeheten owner 
recordtype, of kortweg owner, het andere recordtype is het zogehe- 
ten member recordtype of kortweg member. Bij elke occurrence van 
de owner horen nu n (n 2 0) occurrences van de member, met 

dien verstande dat een oecurrence van de member bij precies één 
occurrence van de owner hoort. 


Opmerking | 
Bij de bespreking van het begrip membership in hoofdstuk 12 zal 
blijken dat de voorafgaande zin volgens de geldende regels van het 
netwerkmodel moet luiden: bij elke occurrence van de owner horen 
nu n (n > 0) occurrences van de member, met dien verstande dat 
een occurrence van de member bij hoogstens een occurrence van 
de owner hoort. 

Wij gaan in dit en de volgende twee hoofdstukken uit van de eer- 
ste versie, dus zonder "hoogstens". D 


In het schema worden 19 settypes gedefinieerd. De naam van de 
eerste zes settypes begint met "SYS". Deze eerste zes settypes zul- 
len wij voorlopig buiten beschouwing laten. Van de overige dertien 
nu enkele voorbeelden. 


Voorbeeld 9.1 


Het settype P-OPN heeft als owner het recordtype P (r. 230) en als 
member het recordtype OPN (r. 231). In het settype P-PATBEH 
komt P weer als owner voor (r. 240), maar nu is PATBEH member 
(r. 241). In het settype OPN-PATBEH is OPN owner (r. 248) en 
PATBEH member (r. 249). D 


Een settype kan als volgt, met een zogeheten Bachman-diagram, in 
beeld worden gebracht. 


member 
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Voorbeeld 9.2 


Het Bachman-diagram voor de settypen van voorbeeld 9.1 is als 
volgt: 


OPN-PATBEH 


PATBEH 


Eenzelfde recordtype kan in meer dan één settype optreden als 
owner en/of member. Hierdoor is een 'netwerk' van verbanden moge- 
lijk tussen de recordtypen. Daarvandaan de naam netwerkmodel. 
Hierbij geldt overigens een merkwaardige beperking: een recordtype 
kan binnen een settype niet tegelijk owner en member zijn. 


P-PAT BEH 


Voor de volledigheid moet worden opgemerkt, dat volgens het DBTG- 

voorstel ook settypen mogelijk zijn met meer dan één membertype. 

In de praktijk wordt hier vrijwel geen gebruik van gemaakt, omdat 

het 

- eigenlijk een overbodige faciliteit is (zeker gezien vanuit de 
logische structuur); 

- in verschillende netwerk-DBMS-en niet geimplementeerd is (dit 
geldt ook voor DBMS-20 van DEC). 


Naar analogie van recordoccurrences bij recordtypen spreekt men bij 
settypen van setoccurrences. Een setoccurrence van een bepaald 
settype is een verzameling, bestaande uit precies één owneroccur- 
rence ën de bij deze owneroccurrence behorende memberoccurrences. 

Een setoccurrence, die alleen bestaat uit een owneroccurrence, 
heet een lege setoccurrence. Bij de definitie van een settype moet 
worden vastgelegd hoe de records per setoccurrence moeten worden 
‘samengevoegd! en in welke ordening deze samenvoeging moet plaats- 
vinden. Voor de samenvoeging zijn twee manieren beschikbaar, 
namelijk met behulp van 
- een kettingstructuur, of 
- een pointer-array. 
Bij gebruik van een ketting per setoccurrence wordt in het owner- 
record een (adres)verwijzing opgenomen naar het 'eerste' bijbeho- 
rende member-record. Dit 'eerste' heeft een verwijzing naar het 
'tweede', enz. Het 'laatste' member-record heeft een verwijzing 
(terug) naar de owner. x 

Bij gebruik van een pointer-array staan genoemde (adres)verwij- 
zingen niet in de records maar in een apart array. 

Beide manieren staan onderstaand in figuur 9.1 schematisch weer- 
gegeven voor een setoccurrence met vijf memberoccurrences. 


132 


Met ketting: 


-M4 [V 5 | 
Met pointer-arrav: 


(mil [m2] (ms) Mal (us) 


Figuur 9.1 Schematische weergave van ketting en pointer-array. 
OW: owneroccurrence 
M1,...,M5: memberoccurrences 
V1,...,V5: adresverwijzing naar volgende member- 
occurrence | 
V0: adresverwijzing naar owneroccurrence. 


In het schema van $ 9.2 komt uitsluitend de kettingstructuur voor 
(MODE IS CHAIN) (r. 128, 136, enz.). 


Als men vanuit een memberoccurrence de bijbehorende ow neroccur- 
rence wil benaderen, zit er (zonder verdere voorzieningen) niets 
anders op dan de hele ketting 'af te lopen' totdat men bij deze 
owneroccurrence is 'aangeland'. Er is echter een mogelijkheid om een 
‘kortsluiting’ tot stand te brengen met behulp van de clausule 
"LINKED TO OWNER". In het schema komt dit bijvoorbeeld voor in 
regel 222 in de beschrijving van het settype SP-PATBEH. Dit laatste 
betekent dat er bij elke occurrence van PATBEH een adresverwij- 
zing is opgenomen naar de SP-occurrence, dat owner is van deze 
PATBEH-occurrence. Zie figuur 9.2. 


Mm2|v3|vo j—-iM3/v4V0 j—-iM41V5/v01—-1M5 [VO JVO 


Figuur 9.2 Ketting ċn linked to owner (vgl. fig.9.1). 
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Uit het bovenstaande blijkt dat het netwerkmodel toch een zekere 
'hang' heeft naar hiërarchische structuren, omdat de toegang van 
owner naar member (via ketting of pointer-array) verplicht is en de 
omgekeerde toegang facultatief. Dit betekent, in geval alleen de 
laatste toegang nodig is, een onnodig stuk onderhoud voor de eerste, 
niet benodigde, toegang. 


De ordening binnen een setoccurrence kan zijn 

- SORTED of 

— FIRST, LAST, NEXT, PRIOR 

In het geval "ORDER IS SORTED" wordt enkele regels eronder met 
ASCENDING/DESCENDING KEY-clausules aangegeven hoe de 
memberrecords per setoccurrence gesorteerd zijn. 

Met FIRST, respectievelijk LAST wordt bedoeld, dat elke nieuwe 
occurrence van het memberrecordtype als eerste respectievelijk laat- 
ste in de setoccurrence (ketting of pointer-array) moet worden 
opgenomen. 

In geval van NEXT respectievelijk PRIOR vindt opname plaats 
volgend op respectievelijk voorafgaand aan de recordoccurrence, die. 
de current of settype aangeeft (voor dit laatste begrip zie het vol- 
gende hoofdstuk, $ 10.1). 

Met behulp van setoccurrences kunnen de recordoccurrences van 
het memberrecordtype groepsgewijze ('sequentieel') worden opgesla- 
gen en benaderd. Hierbij zal het aantal groepen gelijk zijn aan het 
aantal occurrences van het ownertype. 

Om alle occurrences van een recordtype als een groep (sequen- 
tieel) te kunnen benaderen, moet een apart settype worden gedefi- 
nieerd, met genoemd recordtype als member en met precies één set- 
occurrence. Aangezien de owner er niet toe doet', wordt deze 'taak' 
door het DBMS 'overgenomen' en zal de owner de standaardnaam 
'SYSTEM' krijgen. Zie de eerste zes settypen in het schema. Een 
settype met SYSTEM als owner wordt ook wel een singular set 
genoemd. 

Het volledige Bachman-diagram, behorende bij het schema van 
$ 9.2 ziet eruit als in figuur 9.3 (singular sets zijn gestippeld 
weergegeven). 


Als we het Bachman-diagram in figuur 9.3 vergelijken met het dia- 
gram met sterfuncties in figuur 8.1, valt onmiddellijk de grote gelij- 
kenis op. Deze gelijkenis is als volgt te verklaren. 

- Stilzwijgend hebben wij verondersteld, dat voor elk object in de 
ziekenhuis-database van hoofdstuk 7 een recordtype zal worden 
gedefinieerd bij weergave in het netwerkmodel. 

Hiermee blijft de 'normaalvorm' behouden. Let wel: het netwerk- 
model spreekt zich niet uit over (gewenste) normalisatie, kent dit 
begrip zelfs niet, maar er is natuurlijk niets tegen om ook in het 
netwerkmodel met een genormaliseerde database te werken. Het 
netwerkmodel leent zich daar trouwens uitstekend voor door 
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dur 

Ha i 

TTE E et 54 iq mager = = VE vga 
rSYS-MED- - - - - J | Lsys-AFD— | 
| -SYS-BEH- — - - - 1 ULsys-SP- | 
Ka ee R 


| 

| 

| 

| L 
I 

l VPR-OPN 
l 

SP-OPN 


OPN-PATBEH 


SP-PATBEH 


MED-MEDVER 


SP-MEDVER 


Figuur 9.3 Bachman-diagram van de ziekenhuis-database. 


— enerzijds de mogelijkheid tot definitie van settvpen 'tussen' 
elk willekeurig tweetal recordtypen 
— en anderzijds de beperking dat settypen alleen maar gebruikt 
mogen worden voor de weergave van één-op-veel (1:n) ver- 
banden tussen owner en member. 
Met dit laatste wordt bedoeld (vergelijk $ 5.4), dat bij een 
owner-occurrence een aantal van n (n 2 0) memberoccurrences 
horen èn bij een memberoccurrence precies één owneroccurrence. 
In het verzamelingsmodel kan in een genormaliseerd databasetype 
een veel-op-veel (n:m) verband tussen twee objecten alleen wor- 
den weergegeven met behulp van een apart object met bijbeho- 
rend tabeltype en twee ssr's. Evenzo kan een (n:m) verband 
tussen twee recordtypen in een ‘genormaliseerd! netwerkschema 
alleen worden weergegeven met behulp van een zogeheten link- 
record en twee settypen, die beide dit link-record als member 
hebben. 
Analoge beweringen gelden voor een (nl:n2:n3) verband tussen 
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drie recordtypen. Zie bijvoorbeeld het ni:n2:n3 verband tussen 
de recordtypen P, SP en VPR, weergegeven door middel van het 
link-record OPN. | 

Elke combinatie van een sterfunctie met een pijlin figuur 8.1 is 
de weergave van een (n:1) verband tussen twee objecten (een 
pijl stelt in feite het ext-gedeelte voor). Wil men dit verband 
behouden in een netwerkschema, dan kan men dit eenvoudig 
waarmaken met behulp van een settype (en in het diagram met 
een ‘omgekeerde! pijl). Wij vinden alle combinaties van een ster- 
functie met een pijl in figuur 8.1 'terug' in figuur 9.3 in de vorm 
van settypen. (Alleen de combinaties vk* met pijl naar vk en 
spec' met pijl naar sp vinden wij in figuur 9.3 niet terug. Hier is 
namelijk in feite sprake van een (1:1) verband en daarvan is de 
weergave met behulp van een settype wel technisch mogelijk, 
maar niet erg zinvol.) 

Er zij op gewezen dat bij deze gelijkenis tussen de figuren 8.1 en 
9,3 een belangrijk verschil tussen het verzamelingsmodel en het 
netwerkmodel niet uit het oog moet worden verloren, namelijk dat 
een ssr geen adequaat equivalent heeft in het netwerkmodel. Zo 
kan bijvoorbeeld via het schema niet geëist worden, dat elke 
waarde van PB-P-NR in de recordoccurrences van PATBEH, ook 
voorkomt als waarde van P-NR in een occurrence van P. Dit is 
namelijk niet hetzelfde als de eis dat tussen de recordtvpen P en 
PATBEH een (1:n) verband moet bestaan, hetgeen in het net- 
werkmodel wel is weer te geven met behulp van een settvpe. 


Tot nu toe is bij het onderwerp record-benadering alleen de groeps- 
gewijze benadering (via setoccurrences) aan bod geweest. Er is 
echter ook de mogelijkheid om één record, los van andere records, 
apart te benaderen, mits in de definitie van het desbetreffende 
recordtype daartoe de juiste voorzieningen zijn getroffen en wel door 
geschikte keuze van de LOCATION MODE-clausule. 

Bij deze clausule bestaan de volgende opties. 


LOCATION MODE IS 


a. DIRECT | 
b. CALC USING <identifier(s) > 
c. VIA <set-name> SET. 


Aparte benadering van één enkel record is mogelijk als optie a of b 
van de LOCATION MODE wordt gebruikt in de beschrijving van het 
desbetreffende recordtype. Bij optie c is deze directe benadering 
niet mogelijk. Met deze optie c wordt bedoeld aan te geven dat elke 
occurrence van het desbetreffende recordtype 'zo gunstig mogelijk! 
met het oog op het genoemde settype moet worden opgeslagen. Zo 
zijn de afdelingsrecords niet direct te benaderen, omdat voor deze 
records geldt LOCATION MODE IS VIA SYS-AFD (r. 54). Andere 
voorbeelden in r. 29, 64, 73, 96 en 118. 
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Bij optie a is wel directe benadering mogelijk, mits men kan 
beschikken over de zogeheten databasekey. Een databasekey iden- 
tificeert elke recordoccurrence uniek binnen de totale database. Het 
is een item, dat door het DBMS wordt beheerd en dan ook niet in het 
schema hoeft te worden opgenomen. Wel mag een gebruiker een veld 
definiëren dat een databasekey-waarde kan bevatten. Wij komen 
hierop terug bij de behandeling van currencv-problemen ($ 10.1). 

In optie b is CALC een afkorting van CALCULATION, aangevend 
dat een berekening moet plaatsvinden om de plaats (LOCATION) van 
een record vast te leggen. Deze berekening zal gebruik maken van 
(USING) de door de gebruiker opgegeven identifier(s). De toevoe- 
ging DUPLICATES NOT ALLOWED betekent dat elke mogelijke waar- 
de van genoemde identifier(s) niet meer dan eenmaal mag voorkomen, 
dus dat genoemde identifier(s) een sleutel bevatten van het desbe- 
treffende recordtype. Met deze toevoeging is optie b gelijk aan het 
geval van sleutelconversie met behulp van een hashing-functie in 
de klassieke bestandsorganisatie (LUNREM, hfdst.6). In het schema 
van $ 9.2 komt de LOCATION MODE IS CALC alleen voor met de toe- 
voeging DUPLICATES NOT ALLOWED. | 


In deze paragraaf zijn nu alle elementen van de record-definities in 

het schema van $ 9.2 ter sprake gekomen; van de set-definities zijn 

nog niet behandeld 

— de zogeheten membership-clausule, die in het schema in de vorm 
AUTOMATIC MANDATORY (of andersom) voorkomt, en 

— de SET SELECTION-clausule. 

De begrippen membership en SET SELECTION komen in het laatste 

hoofdstuk aan bod. 


Uit het voorgaande mogen al wel de volgende conclusies duidelijk zijn. 

- Een objectkarakterisering laat zich goed weergeven in het net- 
werkmodel. 

- Het netwerkmodel kent geen tupelconstraints, tabelconstraints 
(behoudens impliciete sleutel-definitie) of databaseconstraints 
(behoudens ‘onvolledige! ssr's). Er kunnen dan ook alleen maar 
(vrijwel) constraint-loze typen in worden weergegeven. 

— In het netwerkmodel is men bij de weergave van de logische 
structuur verplicht veel aandacht te besteden aan zaken betref- 
fende de opslagstructuur (LOCATION MODE- en AREA-clausules 
bij de beschrijving van recordtypes; MODE IS CHAIN, ORDER- 
clausule en de nog te bespreken SET SELECTION-clausule bij de 
beschrijving van settvpes). 
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OPGAVEN 


9.1 Ontwerp een schema met bijbehorend Bachman-diagram voor 
a. databasetype DT-HANDEL-1 (voorbeeld 6.1) en voor 
databasetype DT-HANDEL-2 (voorbeeld 6.4); 
b. het databasetype van opgave 6.3. 


9.2 Deze opgave heeft betrekking op het schema van $ 9.2. Verder 
wordt uitgegaan van de volgende aantallen occurrences per 


recordtype: 
recordtype aantal occurrences 
P 10000 
VK 140 
SP 30 
AFD 10 
VPR 40 
OPN 20000 
BEH 100 
PATBEH 40000 
MED 200 
MEDVER 50000 
a. Geef het aantal recordoccurrences per area. 
b. Geef commentaar op de volgende beweringen. 


bi. De occurrences van alle recordtypen, die als owner in 
een settype voorkomen, kunnen direct worden benaderd. 

b2. Een setoccurrence van het settype SYS-AFD bevat 
gemiddeld een recordoccurrence. 

b3. Een setoccurrence van het settype P-PATBEH bevat 
gemiddeld een occurrence van recordtype P en vier 
occurrences van recordtype PATBEH. 

b4. Een setoccurrence van het settype P-PATBEH kan leeg 
zijn. 

c. Kan "LINKED TO OWNER" van belang zijn voor het settype 
P-OPN? 


10 RETRIEVAL IN HET NETWERKMODEL; 
CURRENCY 


10.1 FIND- EN GET-OPDRACHT; CURRENCY 


In het DBTG-model werkt men met een host language (vgl. $ 1.3). 
In ons geval zal dat COBOL zijn. Deze taal is daartoe uitgebreid met 
enkele DML-opdrachten voor 

“< onderhoud (maintenance), en 

- gebruik (retrieval. 

In het volgende hoofdstuk zal onderhoud worden behandeld. In dit 
hoofdstuk beperken wij ons tot retrieval. 


Voor retrieval zijn twee opdrachten beschikbaar, namelijk de FIND- 
en de GET-opdracht. De FIND-opdracht dient om de plaats van een 
recordoccurrence in de database te bepalen; met de GET -opdracht 
wordt een recordoccurrence ingelezen in het werkgeheugen. 

In een FIND-opdracht moet altijd het volgende aanwezig zijn: 


FIND <record-selection-expression>. 


Wij zullen 'rse' gebruiken als afkorting van 'record-selection- 
expression'. Wij zullen in dit boek alleen de volgende drie soorten 
rse's bespreken, namelijk die welke betrekking hebben op 


rsel: directe toegang tot een recordoccurrence 
rse2: seriële toegang binnen een setoccurrence 
rse3: directe toegang tot de owner binnen een setoccurrence. 


De 'nummering' rsel, rse2 en rse3 geldt enkel voor dit boek; in de 
meeste boeken en manuals wordt de nummering van officiële DBTG- 
specificaties aangehouden. 


De vorm van de drie rse's is als volgt: 
rsel: <recordname> RECORD 


NEXT 
PRIOR 
rse2: FIRST RECORD OF <setname> SET 


LAST 
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rse3: OWNER OF <setname> SET 


met de volgende betekenis (waarbij er voorlopig van uitgegaan 
wordt, dat alle opdrachten uitvoerbaar zijn). 


Ad rsel 

Deze kan alleen worden toegepast op recordtypen met LOCATION 
MODE IS CALC. Door aan de USING-identifier(s) de juiste waarde te 
geven kan verder met een FIND-opdracht de plaats van het gewens- 
te record worden gevonden. 


Voorbeeld 10,1 (op het schema van $ 9.2) 
Met 


MOVE 10 TO P-NR 
FIND P RECORD 


wordt de plaats bepaald van het patiënt-record met patiëntnummer 
10. n 


Ad rse2 
In een FIND-opdracht moet een van de vier tussen accoladen 
genoemde mogelijkheden worden gebruikt. 
Met NEXT 
PRIOR 
FIRST 
LAST wordt de plaats bepaald van 


het volgende 
vorige 
eerste 
laatste memberrecord 


van een bepaalde setoccurrence van het <setname> type. 


Voorbeeld 10.2 (op het schema van $ 9.2) 
Met 


MOVE 10 TO P-NR 

FIND P RECORD 

FIND FIRST RECORD OF P-OPN SET 
FIND NEXT RECORD OF P-OPN SET 


wordt achtereenvolgens de plaats bepaald van: 


1. het patient-record met patiëntnummer 10; 

2. het eerste opname-record in de setoccurrence met genoemd 
patiënt-record als owner; 

3. het tweede opname-record in dezelfde setoccurrence. n 
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Ad rse3 
Met een FIND-opdracht wordt de plaats bepaald van het owner- 
record van een setoccurrence. 


Voorbeeld 10.3 (op het schema van $ 9.2) 
Met 


MOVE 10 TO P-NR 

FIND P RECORD 

FIND FIRST RECORD OF P-OPN SET 
FIND OWNER OF SP-OPN SET 

FIND NEXT RECORD OF P-OPN SET 
FIND OWNER OF SP-OPN SET 


wordt achtereenvolgens de plaats bepaald van: 


1. het patiënt-record met patiëntnummer 10; 

2. het eerste opname-record in de setoccurrence met genoemd 
patiënt-record als owner; 

3. het specialist-record, dat owner is van de setoccurrence waarin 
het opname-record sub 2 als member voorkomt ; 

4. het tweede opname-record in de setoccurrence, genoemd sub 2; 

5. het specialist-record, dat owner is van de setoccurrence waarin 
het opname-record sub 4 als member voorkomt. o 


Tot zover (hopelijk) geen problemen. 
Wat echter te denken van het volgende voorbeeld? 


Voorbeeld 10.4 (op het schema van $ 9.2) 
Gegeven het programmadeel 


MOVE 10 TO P-NR 

FIND P RECORD 

FIND FIRST RECORD OF P-OPN SET 
FIND OWNER OF SP-OPN SET 

FIND FIRST RECORD OF SP-OPN SET 
FIND NEXT RECORD OF P-OPN SET 


Op 'het eerste gezieht' lijkt het dat met de laatste FIND hetzelfde 
opname-record wordt gevonden als opname-record sub 4 van voor- 
beeld 10.3. Dit is echter niet juist. o 


Het probleem met het laatste voorbeeld is, dat wij niet precies het 
volledige effect van een FIND-opdracht kennen. Daarvoor zullen wij 
het zogeheten currency-probleem moeten bespreken. 

Daarbij moeten wij gebruik maken van de reeds eerder genoemde 
databasekey. Zoals gezegd wordt met de databasekey (de plaats van) 
elke recordoccurrence in de database uniek vastgelegd. In principe 
hoeft de gebruiker niets van de databasekey of zelfs maar van het 
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bestaan daarvan te weten. Voor een goed begrip van het currency- 
probleem moeten wij er echter wel even aandacht aan besteden. 

Wij zullen aannemen dat (zoals trouwens in verschillende imple- 
mentaties ook het geval is) de databasekey-waarden bestaan uit een 
volgnummer per recordtype, gevolgd door een volgnummer per 
recordoccurrence binnen een recordtype. In onderstaand voorbeeld 
10.5 staan deze waarden genoteerd in de kolom 'databasekev'. 


Voorbeeld 10.5 


Gegeven is het volgende gedeelte van een schema, met weglating van 
voor dit en volgende voorbeelden niet ter zake doende AREA- 
clausules. 


SCHEMA NAME IS VB10 


RECORD NAME IS A 
LOCATION MODE IS CALC USING Al 
DUPLICATES NOT ALLOWED. 
02 Al PIC 99. 
02 A2 PIC 99. 


RECORD NAME IS B | 
LOCATION MODE IS CALC USING B1 
DUPLICATES NOT ALLOWED. 
ġġ BL: Pic (190, 
tA. B? PIP 09: 


RECORD NAME IS C 
LOCATION MODE IS VIA AC 
02 C1 PIC 99. 
02 C2 PIC 99; 
02 C3 PIC 99; 


SET NAME IS SYS-A 
MODE IS CHAIN 
ORDER IS SORTED 
OWNER IS SYSTEM 
MEMBER IS A 
AUTOMATIC MANDATORY 
ASCENDING KEY IS Al. 


SET NAME IS AC 
MODE IS CHAIN 
ORDER IS SORTED 
OWNER IS A 
MEMBER IS C 
AUTOMATIC MANDATORY 
ASCENDING KEY IS C2 
SET OCCURRENCE SELECTION IS THRU 
CURRENT OF SET. 
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SET NAME IS BC 

MODE IS CHAIN 
ORDER IS ALWAYS LAST 

OWNER IS B 

MEMBER IS C 
AUTOMATIC MANDATORY 
SET OCCURRENCE SELECTION IS THRU 

CURRENT OF SET. 


END-SCHEMA 


Het bij bovenstaand schema behorende Bachman-diagram is 


SYS-A 


In onderstaande tabel worden de recordoccurrences gegeven met 
bijbehorende waarden van de databasekey. 


Al A2 base- B2 


6 Ze 1 29 18 3.07 
1 2. 1 9 15 3.02 
2 2. 1 12 52 3.13 
7 2. 1 23 40 3. 32 
7 2. 1 16 17 3.01 
2 2. 2 23 11 3.29 
6 2. 2 5 51 3.03 
8 du 2 12 05 3.04 
5 2. 2 57 54 3.05 
7 9 08 3.10 
'Gaten' in een volgnummerserie 7 26 75 3. 
van de databasekev worden 7 12 56 8: 
verondersteld veroorzaakt te 3, 
zijn door verwijdering van 3. 
recordoccurrences. 3. 
$, 
3. 
3k 
3. 
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Verder worden nog de volgende veronderstellingen gemaakt : 

- Elk C-record zal binnen settype AC behoren tot de setoccurrence 
waarvan de owner voor Al dezelfde waarde heeft als C voor C1. 

- Elk C-record zal binnen settype BC behoren tot de setoccurrence 
waarvan de owner voor B1 dezelfde waarde heeft als C voor C2. 

— Per setoccurrence van settype BC zijn de C-records toevallig! 
naar oplopende databasekey-waarde geordend. o 


Zoals bekend dient de FIND-opdracht om de plaats van een record- 
occurrence in de database te bepalen. Dit kan gevoegelijk zo worden 
voorgesteld dat de FIND-opdracht de databasekey-waarde levert 
van de recordoccurrence, die wordt gespecificeerd met de rse. 


Voorbeeld 10.6 
(zie gegevens in voorbeeld 10.5) 
Met het programmadeel: 


MOVE 7 TO A1 

FIND A RECORD 

FIND FIRST RECORD OF AC SET 
FIND OWNER OF BC SET 

FIND NEXT RECORD OF AC SET 
FIND OWNER OF BC SET 


komen achtereenvolgens de volgende databasekey-waarden beschik- 
baar: 
1 08: $.10; 2.16; 9.19; 2.09. (Men ga dit na!) o 


Een netwerk-DBMS kent per programma verschillende zogeheten 
currency-indicators (systeemgrootheden) en wel een indicator voor 
het onderhanden zijnde programma, een indicator voor elk record- 
type en een indicator voor elk settype. Ook is er voor elke area een 
indicator, maar deze kunnen wij hier gevoegelijk buiten beschou- 
wing laten. 


De indicator voor het programma, de zogeheten current of run-unit, 
bevat het resultaat van de laatst uitgevoerde FIND-opdracht, in de 
vorm van de databasekey-waarde van het record, dat 'onderwerp' 
was van deze FIND. 

De indicator van recordtype A, de zogeheten current of record- 
type A, bevat de databasekey-waarde die resulteerde uit de laatste 
FIND-opdracht op recordtype A. 

De indicator van settype AC, de zogeheten current of settype 
AC, bevat de databasekey-waarde, die resulteerde uit de laatste 
FIND-opdracht op het owner- of memberrecordtype van settype AC. 

Door een FIND-opdracht, waarbij R het record is dat bepaald is 
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door de rse, krijgen de volgende currencv-indicators de waarde 

van de current of run-unit: 

— current of recordtvpe van het recordtype waartoe R behoort; 

— current of settype van elk settype waarvan R owner of 
member is. 


Ter illustratie het volgende voorbeeld. 


Voorbeeld 10.7 
(zie gegevens in voorbeeld 10.5) 


In onderstaande tabel wordt links een programmadeel gegeven en 
rechts per currency-indicator wat het resultaat is van de desbe- 
treffende opdracht. Hierbij betekent : 

— : waarde currency-indicator onbekend 

$ waarde currency-indicator wordt niet beinvloed door opdracht 


current of 
recordtype settype 
Programmadeel 
a jee Ap al oa ek 


MOVE 7 TO Al ma 


| 
| 
| 
í s. del š 3.10 | 3.10 


FIND A RECORD 1.02 f 1.02 | - - 1.02 |1.02 | - 

FIND FIRST RECORD OF AC SET | 3.10 

FIND OWNER OF BC SET xP A ec 3 š 2.16 

FIND NEXT RECORD OF AC SET | 3.12 , 3.12 | 8.42 | 3.12 

FIND OWNER OF BC SET CERN , 2.09 I - À ` 2.09 
D 


Met het volgende voorbeeld wordt een probleem, analoog aan dat 
van voorbeeld 10.4, behandeld. 


Voorbeeld 10.8 


Als voorbeeld 10.7, maar met een ander programmadeel. 


current ES 

Programmadeel settype 
MOVE 7 TO Al - | - 
FIND A RECORD 1.02 l 1.02] - í A 1.02 iiai - 
FIND FIRST RECORD OF AC SET | 3.10 8 - 3.10 N 3.10 | 3.10 
FIND OWNER OF BC SET 2.16 Š 2.16 ü A ñ 2.16 
FIND FIRST RECORD OF BC SET | 3.02 à š 3.02 i 3.02 | 3.02 
FIND NEXT RECORD OF AC SET AIS S Ë 3.138 y LEE ERR 


Zou men in bovenstaand voorbeeld de currencv-indicator van AC 
‘onverlet! op de waarde 3.10 willen laten staan en dus niet door de 
voorlaatste FIND-opdracht 'verminkt' laten worden, dan kan dit 


145 


gebeuren door in de voorlaatste FIND-opdracht gebruik te maken 
van het zogeheten SUPPRESS-gedeelte in de FIND-opdracht. De 
voorlaatste opdracht zou dan luiden: 


FIND FIRST RECORD OF BC SET SUPPRESS AC 


Als deze opdracht dan zou worden gevolgd door FIND NEXT 
RECORD OF AC SET, zou de currencv-indicator van settype AC de 
waarde 3.12 krijgen. 

In het algemeen kan met de SUPPRESS-clausule in een FIND- 
opdracht de verandering van currencv-indicators worden 'onder- 
drukt ', behalve de current of run-unit. Deze laatste kan nooit wor- 
den onderdrukt. 

In het geval 'tweemaal achter elkaar' op hetzelfde settvpe 'ver- 
minking' van de currencv-indicator dreigt plaats te vinden, is de 
zaak met de SUPPRESS-clausule 'niet te redden'. Men zal dan de 
(meest algemene) methode moeten volgen, waarbij gebruik wordt 
gemaakt van items van het type databasekey. In dit boek wordt hier 
niet op ingegaan. Men zij verwezen naar de specifieke DBTG-litera- 
tuur of naar een manual. 


In het voorgaande hebben wij steeds verondersteld, dat elke FIND- 

opdracht uitvoerbaar was. Er kunnen echter redenen zijn waarom 

een FIND-opdracht niet uitvoerbaar is. Om de (voor ons) belangrijk- 

ste te noemen: 

— met rsel: de gegeven waarde(n) van de USING-identifier(s) komt 
(komen) niet voor in de database; 

— met rse2: bij gebruik van FIND NEXT: er is geen volgende 
memberoccurrence in de setoccurrence; 

- gebruik van verkeerde namen: bijvoorbeeld AAC in plaats van AC. 


Om niet-uitvoerbare FIND-opdrachten te kunnen signaleren (èn ook 
te kunnen signaleren dat een FIND-opdracht wèl uitvoerbaar is) 
heeft een netwerk-DBMS per programma een systeemparameter met de 
naam ERROR-STATUS. 

Na het succesvol uitvoeren van een FIND-opdracht krijgt ERROR- 
STATUS de waarde 0, en anders een waarde £ 0. In dit laatste geval 
kan men aan de waarde zelf al enigszins zien 'wat er misgegaan is', 
bijvoorbeeld ERROR-STATUS = 0308 betekent '"record- of setnaam 
onbekend", en ERROR-STATUS = 0307 betekent "einde van setoccur- 
rence". Wij zullen alleen maar onderscheid maken tussen "= 0" en 
"£ 0". Men bedenke verder wel, dat per programma niet meerdere 
ERROR-STATUS-velden beschikbaar zijn, maar precies één. 


Als een FIND-opdracht succesvol is verlopen, kan men met een GET- 
opdracht de recordoccurrence die ‘aangewezen! wordt door de current 
of run-unit in het werkgeheugen inlezen. De algemene vorm van een 
GET-opdracht is: ` 


GET <recordname> 
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Voorbeeld 10.9 
(zie gegevens in voorbeeld 10.5 en vergelijk met voorbeeld 10.7) 
Met 


MOVE 7 TO Al 

FIND A RECORD 

GET A 

FIND FIRST RECORD OF AC SET 
GET C 

FIND OWNER OF BC SET 

GET B 

FIND NEXT RECORD OF AC SET 
GET C 

FIND OWNER OF BC SET 

GET B 


worden achtereenvolgens de volgende recordoccurrences in het 
werkgeheugen ingelezen (hier aangegeven met hun databasekey- 
waarde): 

1.02: 3.10: 2:16::3, 185000 m 


Wij zullen nu in de volgende paragraaf enkele van de retrieval- 
voorbeelden van hoofdstuk 8 behandelen met de DML van het net- 
werkmodel. 


10.2 RETRIEVAL OP DE ZIEKENHUIS-DATABASE 


In het verzamelingsmodel werden de gestelde vragen op de zieken- 
huis-database op verzamelingsniveau beantwoord. Bij een netwerk- 
DBMS wordt dikwijls een apart (query-language) pakket aangeboden, 
dat behandeling van vragen op verzamelingsniveau min of meer 
mogelijk moet maken. De ervaring met dergelijke pakketten is nog 
erg gering, niet in het minst omdat de performance bij een wat grote 
database nogal eens te wensen overlaat. 

= De eigenlijke aanpak bij een netwerk-DBMS is die op recordniveau 
met behulp van de FIND- en GET-opdrachten. 

Wij zullen nu enkele voorbeelden van hoofdstuk 8 behandelen met 
behulp van juist genoemde opdrachten en uitgaande van het schema 
van § 9.2. Wij geven de oplossingen dan in eerste instantie weer met 
behulp van een Pascalachtige referentietaal, zoals ook wordt 
gebruikt in (LUNREM). Uiteraard zijn in deze referentietaal een 
find- en een get-opdracht mogelijk. 

Verder zullen wij daarin kunnen beschikken over de boolean 
functie: 


end (<setname>) 
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Deze functie krijgt de waarde true respectievelijk false als na de uit- 
voering van een FIND rse2 opdracht op <setname> ERROR-STATUS 
= 0 respectievelijk ERROR-STATUS £ 0 is. 


In tweede instantie zullen wij ook nog een enkel voorbeeld weergeven 
in de hostlanguage COBOL. 


Voorbeeld 10,10 (vgl. voorbeeld 8.2) 
Vraag 


Geef naam, adres en woonplaats van de specialisten die de behande- 
ling met code KNO6 hebben verricht. 


Analyse 


Wij brengen nog even het antwoord van voorbeeld 8.2 in herinnering: 


get ({t/ {snm ,sadr,swpl} | t € zkh(sp) A 


Ju € zkh(pb)lu(snr) = t(snr) A u(bed) = KNO6] }). 


mt blijkt dus duidelijk het volgende: 
"t € zkh(sp)" geeft aan dat elk specialist-record in behandeling 
moet worden genomen, en daarbij geeft 

— Ju € zkh(pb)[u(snr) = t(snr) A u(bed) = KNO6] aan dat wij, 
vanwege ''u(snr) = t(snr)'' vanzelf in de goede richting zoeken, 
als wij bij elk specialist-record de bijbehorende setoccurrence van 
settype SP-PATBEH 'nalopen'. Dit nalopen kunnen wij overigens 
stoppen als wij een patiëntbehandeling-record hebben gevonden 
met behandelcode KNO6. 


Na deze analyse moge het nu volgende antwoord duidelijk zijn. 
Uiteraard was een dergelijke analyse ook mogelijk geweest zonder 
het letterlijke antwoord van voorbeeld 8.2. In ieder geval is een 
verzamelingsanalyse dikwijls erg nuttig zo niet onmisbaar. Antwoor- 
den in de referentietaal zullen wij, behoudens schema-elementen van 
$ 9.2, in kleine letter geven en antwoorden in COBOL in grote 
letter. 


Antwoord 


var found: boolean 
endvar; 
find first record of SYS-SP set; 
while not end(SYS-SP) 
do get SP; found := false; 
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find first record of SP-PATBEH set; 
while not end(SP-PATBEH) and not found 
do get PATBEH; f 5-1 e 
if PB-BEH-CD = "KNO6" 
then found := true 
else find next record of SP-PATBEH set 
fi 
od; ` 
if found 
then display SP-NM,SP-ADR,SP-WPL 
fi; | 
find next record of SYS-SP set 
od o 


Voorbeeld 10.11 (vgl. voorbeeld 8.6) 
Vraag 


Geef van elke specialist, die in 1980 meer dan tien maal de behande- 
ling KNO7 heeft verricht: naam, adres, woonplaats, het aantal 
malen dat hij deze behandeling heeft verricht in 1980 en de maximale 
en gemiddelde duur van dit aantal. 


Analyse ` 


In de oplossing van voorbeeld 8.6 is duidelijk te zien dat per waar- 
de van specialistnummer de verzameling patiëntbehandelingrecords 
met deze zelfde waarde voor specialistnummer driemaal moet worden 
doorlopen, en wel voor de bepaling van aantal, maximale duur en 
gemiddelde duur. Het aantal wordt gebruikt als onderdeel van de 
voorwaarde èn als onderdeel van het gevraagde. Wij kunnen dit het 
eenvoudigst oplossen door per specialist de gehele erbij behorende 
setoccurrence van settvpe SP-PATBEH door te nemen. 


Antwoord 


var maxd, somd: hoev; tel: integer 
endvar; 
find first record of SYS-SP set; 
while not end (SYS-SP) 
do get SP; tel := maxd := somd := 0; 
find first record of SP-PATBEH set; 
while not end (SP-PATBEH) 
do get PATBEH; 
7 if 800101 < PB-DAT < 801231 and 
7 PB-BEH-CD = ''KNOT' B 
then tel := tel + 1; 
somd := somd + PB-DUUR; 
if PB-DUUR > maxd 
then maxd ze PB-DUUR 
fi 
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find next record of SP-PATBEH set: 
od; 
it tel > 10 
then display SP-NM,SP-ADR, SP-WPL, 
tel ,maxd,somd/tel 
fi; 
find next record of SYS-SP set 
od 


Van dit voorbeeld zullen wij hier ook de COBOL-weergave geven. 


WORKING-STORAGE SECTION 
77 MAXD PIC 9(4), 
77 SOMD PIC 9(10). 
77 TEL PIC 9(6). 
77 GEMD PIC 9(4), 


PROCEDURE DIVISION. 


FIND FIRST RECORD OF SYS-SP SET 
PERFORM VOLGENDE UNTIL ERRORSTATUS > 0. 


STOP RUN. 


VOLGENDE. | 
GET SP. MOVE ZERO TO TEL,MAXD,SOMD. 
FIND FIRST RECORD OF SP-PATBEH SET. 
PERFORM PB UNTIL ERROR-STATUS > 0. 
IF TEL > 10 
COMPUTE GEMD = SOMD/TEL 
DISPLAY SP-NM,SP-ADR, SP-WPL, TEL ,MAXD , GEMD. 
FIND NEXT RECORD OF SYS-SP SET. 


PB. 
GET PATBEH, 
IF PP-DAT 2 800101 AND PB-DAT < 801231 AND 
PB-BEH-CD = "KNO7' 
ADD 1 TO TEL 
ADD PP-DUUR TO SOMD 
IF PB-DUUR > MAXD 
MOVE PB-DUUR TO MAXD. 
FIND NEXT RECORD OF SP-PATBEH SET. o 


Tenslotte een equivalent van voorbeeld 8.11 (gebruik van sterfunc- 
ties en ext-gedeelte). 
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Voorbeeld 10.12 (vgl. voorbeeld 8.11) 
Vraag 


Geef van elke behandeling die in mei 1980 werd verricht door een 
specialist van de afdeling dermatologie: behandelcode en -soort, 
patiëntnummer en -naam, datum, specialistnummer en -naam. 


Analyse 


In het antwoord van voorbeeld 8.11 wordt van elk pb-tupel nagegaan 
of het aan de gestelde voorwaarde voldoet en zo ja, dan wordt het 
gevraagde met driemaal gebruik van sterfunctie met ext-gedeelte 
geleverd. Deze werkwijze kan hier niet worden gevolgd, omdat 
PATBEH geen member is van een singular set. Wij zullen hier dan 
ook starten vanaf de afdeling dermatologie en dan via de daarbij 
behorende specialisten de patiëntbehandelingen afwerken. Voldoet 
een patiëntbehandeling aan de voorwaarden, dan kan met o.a. enke- 
le FIND OWNER-opdrachten het gevraagde worden geleverd. 


Antwoord 


var found: boolean 
endvar ; 
find first record of SYS-AFD set; found := false; 
while not end(SYS-AFD) and not found 
do get AFD; 
if AFD-NM = dermatologie 
then found := true 
else find next record of SYS-AFD set 
fi 
od; 
if found 
then find first record of AFD-SP set; 
while not end(AFD-SP) 
do get SP; 
find first record of SP-PATBEH set; 
while not end(SP- PATBEH) 
do get rh 
if 800501 < PB-DAT <800531 
— thën fimt owner of BEH-PATBEH set; 
find owner of P-PATBEH set; 
displav PB-BEH-CD, BEH-SRT, 
PB-P-NR,P-NM, PB-DAT, 


SP-NM, SP-NR 
fis 
find next record of SP-PATBEH set 
od; 
find next record of AFD-SP set 


od 
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OPGAVEN 


10.1 (zie gegevens in voorbeeld 10.5) 
Gegeven is het volgende programmadeel: 


MOVE 23 TO B1 

FIND B RECORD 

FIND FIRST RECORD OF BC SET 
FIND NEXT RECORD OF BC SET 
FIND FIRST RECORD OF AC SET 
FIND FIRST RECORD OF SYS-A SET 
FIND NEXT RECORD OF AC SET 
FIND OWNER OF BC SET 


Bepaal de waarde van de currency-indicators in de loop van 
het programma. 


10.2 Maak een keuze uit de vragen van opgaven 8.1-8.30 en geef 
het antwoord in het netwerkmodel. 


11 ONDERHOUD IN HET NETWERKMODEL 
MEMBERSHIP 


11.1 ONDERHOUD IN HET NETWERKMODEL 


Het netwerkmodel kent zes soorten onderhoud en dus ook zes ver- 
schillende onderhoudsopdrachten. Deze opdrachten zijn: 


1. STORE voor het invoegen in de database van een nieuwe 
| recordoccurrence 
2. MODIFX voor het veranderen van een of meer items van 
een bestaande recordoccurrenece in de database 
3. DELETE voor het verwijderen uit de database van een 
a bestaande recordoccurrence 
4, CONNECT voor het verbinden met een setoccurrence van een 


bestaande recordoccurrence in de database 

5. RECONNECT voor het veranderen van de verbinding met een 
setoccurrence van een bestaande recordoccurrence 
in de database 

6. DISCONNECT voor het ontkoppelen van de verbinding met een 
setoccurrence van een bestaande recordoccurrence 
in de database. 


Opmerking 

De naam van elk van de zes onderhoudsopdrachten is in de loop der 
tijd (in officiële documenten en in manuals) al meermalen veranderd. 
In dit opzicht kunnen DBMS-pakketten van netwerksignatuur dan 
ook nogal verschillen vertonen. Zo is bij sommige INSERT equivalent 
met bovengenoemd STORE, maar bij andere is INSERT equivalent 
met bovengenoemd CONNECT. D 


De eerste drie opdrachten hebben betrekking op de recordoccur- 
rence zelf (reeds bekend van de bestandsorganisatie, zij het onder 
andere namen) en de laatste drie hebben betrekking op de verbin- 
ding van een recordoccurrence met andere recordoccurrences binnen 
een setoccurrence. Van deze laatste groep zullen wij overigens 
alleen gebruik maken van de RECONNECT-opdracht. Toelichting 
hierop volgt nog in $ 11.2. 
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We zullen nu de verschillende opdrachten afzonderlijk bespreken, 
waarbij wij ons zullen beperken tot de belangrijkste grondvormen. 
Hierbij zullen wij steeds veronderstellen dat wij te doen hebben met 
sets waarvoor geldt SET OCCURRENCE SELECTION IS THRU 
CURRENT OF SET. Dit zullen wij ook veronderstellen bij onder- 
houdsopdrachten op de ziekenhuis-database van $ 9.2, ook als in 
deze het schema anders luidt. Met andere vormen van de SET 
SELECTION-clausule kunnen onderhoudsopdrachten nogal ingewik- 
keld worden. Globaal gesproken wordt met de SET SELECTION- 
clausule weergegeven op welke wijze de geschikte setoccurrences, 
met name bij de STORE-opdracht, gekozen moeten worden. Door ons 
te beperken tot bovengenoemde vorm zal de keuze van setoccur- 
rences steeds plaatsvinden met behulp van de currencv-indicators 
voor de settypes. 


STORE-opdracht 


Deze heeft in het algemeen de vorm: 
STORE <recordname> 


Het effect van een succesvol uitgevoerde STORE-opdracht is: 

- invoeging van de gespecificeerde recordoccurrence in de data- 
base, ên 

— opname in een setoccurrence van elk settype, waarvan het desbe- 
treffende recordtype member is, en 

- creatie van een nieuwe setoccurrence voor elk settype, waarvan 
het desbetreffende recordtype owner is, èn 

- verandering van currency-indicators volgens de gebruikelijke 
regels. 


Voorafgaand aan de STORE-opdracht zullen de nodige voorzieningen 
moeten worden getroffen ten aanzien van juiste itemwaarden van het 
in te voegen record en ten aanzien van juiste waarden van currency- 
indicators. Dit laatste is nodig om de geschikte setoccurrences 
beschikbaar te hebben. 

Kan een STORE-opdracht niet succesvol worden uitgevoerd, dan 
krijgt ERROR-STATUS een waarde > 0. 


Alle voorbeelden in deze paragraaf hebben betrekking op het schema 
van $ 9.2. 

Voorbeeld 11.1 (vgl. voorbeeld 8.12) 

Opdracht 


Voeg de volgende twee opnamerecords, als weergegeven in onder- 
staande tabel, in. 
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OPN-P-NR OPN-R ` OPN-VPR-NR OPN-IN-DAT OPN-UIT-DAT OPN-SP-NR 
15 DATALOGITIS 26 820614 991231 36 
27 DATALOGITIS 28 820614 991231 36 
Analvse 


STORE kan alleen op recordniveau. Er zullen dus twee STORE- 
opdrachten nodig zijn. 

Uit figuur 9.3 blijkt (met een oogopslag) dat OPN member is in drie 
settvpen. Dus zal voor elk van deze drie settvpen vooraf de juiste 
setoccurrence current gemaakt moeten worden, hetgeen met name 
voor het settvpe VPR-OPN nogal omslachtig is. Voor recordtvpe VPR 
geldt namelijk niet LOCATION MODE IS CALC. Voor elk van de beide 
STORE-opdrachten zal uiteraard het voorbereidende werk van 
dezelfde aard zijn. Wij zullen in de oplossing dan ook werken met een 
procedure voeginopn. 


Oplossing (in referentietaal) 


procedure voeginopn (var pnr : integer; 
opnr : charstring; 
vnr 1 integer; 
indat : integer; 
uitdat: integer; 
snr : integer) 
begin var setp,setsp,setvpr: boolean 
endvar; 
P-NR :5 pnr; find P record; 
if ERROR-STATUS > 0 
then setp := false 
else setp := true 
fi; 
SP-NR := snr; find SP record; 
if ERROR-STATUS > 0 
then setsp := false 
else setsp := true 
fis 
find first record of SYS-AFD set; 
setvpr := false; 
while not end(SXS-AFD) and not setvpr 
do ` find first record of AFD-VPR set; 
while not end(AFD-VPR) and not setvpr 
do get VPR; 


ġġ if VPR-NR = vnr 
Ż juiste setoccurrence 


ġi then setvpr := true 
A yad ME else find next record of AFD-VPR set 


Z juiste setoccurrence 
zoeken van P-OPN Z 


Z juiste setoccurrence 
zoeken van SP-OPN Z 


od; 
if not setvpr 
then find next record of SYS-AFD set 
fi 
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if setp and setsp and setvpr 
then OPN-P-NR := pnr; 
OPN-R := opnr; 
Z waarde van in te OPN-VPR-NR := vnr; 
voegen record Z OPN-IN-DAT := indat; 
OPN-UIT-DAT := uitdat; 
OPN-SP-NR := snr; 
Z invoegen Z store OPN 
else display setp,setsp,setvpr 
fi 
Z einde procedureZ end; — 
voeginopn (15, "DATALOGITIS", 26, 820614, 991231, 36); 
voeginopn (27, "DATALOGITIS", 28, 820614, 991231, 36) 


MODIFY-opdracht 


Deze heeft in het algemeen de vorm 
MODIFY <recordname> <datanamelist > 


Het effect van een succesvol uitgevoerde MODIFY-opdracht is de 
verandering van de velden in <datanamelist> van het gespecificeerde 
record in vooraf opgegeven waarden. 

Ook hier geldt weer dat bij niet succesvolle uitvoering ERROR- 
STATUS een waarde > 0 krijgt 


Voorbeeld 11.2 (vgl. voorbeeld 8.14) 
Opdracht 


Verander in het opnamerecord met patiëntnummer 15 en indat 
820614 de uitdat in 820625. 


Analyse 


Aangezien OPN geen LOCATION MODE IS CALC heeft, moet het 
bedoelde opnamerecord gezocht worden via een setoccurrence van 
P-OPN. 


Oplossing 


var found: boolean endvar; 
P-NR := 15; 
find P record; 
if ERROR-STATUS 7 0 
then display "patiënt niet bekend" 
else find first record of P-OPN set; found :- false; 
while not end (P-OPN) and not found 
do get OPN; A SANTA 
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if OPN-IN-DAT = 820614 
then found := true 
else find next record of P-OPN set 


od; ` 
if found 
then OPN-UIT-DAT := 820625 
modify OPN OPN-UIT-DAT 
else display "opname onbekend" 


Fa. | o 


—n 


Bij verandering op meerdere records zijn ook meerdere MODIFY- 
opdrachten nodig. 


Voorbeeld 11.3 (vgl. voorbeeld 8.16) 
Opdracht 


Verminder van elke specialist met een aantal bedden > 0, dit aantal 
met 1. 


Oplossing 


find first: record of SIS-SP set; 
while not end(SXS-SP) 
do get BEZ 
LE SP-AB > O 
— then SP-AB := SP-AB - 1 
modify SP SP-AB 


fi: 
find next record of SYS-SP set 
od a 


DELET E-opdracht 


Deze heeft in het algemeen de vorm 


DELETE <recordname> 


Het effect van een succesvol uitgevoerde DELETE-opdracht is: 

— ontkoppeling van alle setoccurrences, waartoe het gespecificeerde 
record als member behoort ; 

— verwijdering van genoemd record uit de database; dit record is 
het current record of run-unit; 

— current of run-unit krijgt onbepaalde waarde (overige currencv- 
indicators veranderen niet). 
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Een DELETE-opdracht is niet uitvoerbaar als het gespecificeerde 
record owner is van een niet-lege setoccurrence. 


Voorbeeld 11.4 (vgl. voorbeeld 8.13) 
Opdracht 


Verwijder de patiëntbehandelingstupels, die betrekking hebben op 
de patiënt met patiëntnummer 82 en op een behandelingsdatum in 
1980. 


„Analyse 


PATBEH bezit geen LOCATION MODE IS CALC. Dus ook hier weer 
via een setoccurrence en wel van settype P-PATBEH. 


Oplossing 


P-NR re 82; 
find P record; 
if ERROR-STATUS = 0 
then find first record of P-PATBEH set; 
while not end(P-PATBEH) 
do get PATBEH; 
— if 800101 < PB-DAT < 801231 
then delete PATBEH 
fis 
find next record of P-PATBEH set 
od 


fa n 


In voorbeeld 8.15 staat de volgende opdracht: Verander adres, 
woonplaats van specialist 12 in dalweg 18, geldrop en verander zijn 
afdelingsnummer in 7. 

Na deze verandering zou het desbetreffende specialistenrecord 
met een verkeerde setoccurrence van settype AFD-SP zijn verbon- 
den, namelijk met die setoccurrence, waarvan zijn oude afdeling 
owner is. Om dit te corrigeren is een RECONNECT-opdracht nodig. 

Hiermee zijn wij aangeland bij de tweede soort onderhoudsop- 
drachten, namelijk die waarbij de inhoud van een recordoccurrence 
niet verandert, maar wel het verband met andere recordoccurrences 
via verandering van setoccurrence. 


RECONNECT -opdracht 


Deze heeft in het algemeen de vorm: 
RECONNECT <recordname> WITHIN <setname> SET 
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Het effect van een succesvol uitgevoerde RECONNECT-opdracht is 
dat het gespecificeerde record (zijnde het current record of run- 
unit) voor het gespecificeerde settype ontkoppeld wordt van de 
setoccurrence, waarvan het nu een member is, en wordt toegevoegd 
aan de gespecificeerde setoccurrence van hetzelfde settype. 


Voorbeeld 11.5 (vgl. voorbeeld 8.15) 
Opdracht 


Verander adres, woonplaats van specialist 12 in dalweg 18, geldrop 
en verander zijn afdelingsnummer in 7. 


Analyse 


Na verandering van het desbetreffende specialistrecord moet een 
RECONNECT-opdracht plaatsvinden om verbinding met de juiste 
setoccurrence tot stand te brengen. 


Oplossing 


var found: boolean endvar; 
SP-NR := 12; 
find SP record; 
if ERROR-STATUS > 0 
— then display "specialist 12 onbekend" 
else SP-ADR := ''DALWEG 18" 
SP-WPL := ''GELDROP'' 
SP-AFD-NR := 7 
modify SP SP-ADR, SP-WPL, SP-AFD-NR; 
find first record of SYS-AFD set; 


found := false; 
while not end(SYS-AFD) and not found 
do get AFD; EDS? 
— if AFD-NR = 7 
then found := true 
else find next record of SYS-AFD set 
fi 
od; T 


if not found 
then display "afdeling 7 onbekend" 
else reconnect SP within AFD-SP set 
fi 
fi B o 


—— 


Dat de andere twee onderhoudsopdrachten voor opname in of verwij- 
dering uit setoccurrences (CONNECT of DISCONNECT) niet zijn toe- 
gestaan op het schema van $ 9.2 hangt samen met de keuze van 
zogeheten memberships in dit schema. Het begrip membership wordt 
in de volgende paragraaf behandeld. 


159 


11.2 MEMBERSHIP 


In de beschrijving van elk van de 19 settypen in het schema van 
$ 9.2 komt de volgende regel voor: 


AUTOMATIC MANDATORY of MANDATORY AUTOMATIC. 


De volgorde van de woorden AUTOMATIC en MANDATORY doet 
overigens niet ter zake. 

AUTOMATIC bepaalt hoe de verbinding van een nieuwe record- 
occurrence met een setoccurrence tot stand dient te komen, namelijk: 
een STORE-opdracht heeft automatisch een CONNECT-opdracht tot 
gevolg zonder dat deze laatste opdracht gegeven wordt. 

Voor het eerste-verbinding-voorschrift is behalve AUTOMATIC 
ook MANUAL mogelijk. In dit laatste geval kan de eerste verbinding 
met een setoccurrence uitsluitend tot stand komen met een 
CONNECT -opdracht. 

MANDATORY bepaalt wat met eenmaal verbonden recordoccurren- 
ces mag en moet gebeuren, namelijk: een eenmaal verbonden record- 
occurrence moet verbonden blijven, maar niet per se met dezelfde 
setoccurrence. 

Voor het behoud-verbinding-voorschrift is behalve MANDATORY 
ook OPTIONAL mogelijk. Dit laatste houdt in dat een eenmaal ver- 
bonden recordoccurrence niet verbonden hoeft te blijven. 

De volgende vier combinaties zijn dus mogelijk: 


1. AUTOMATIC MANDATORY 
2. AUTOMATIC OPTIONAL 
3. MANUAL MANDATORY 
4, MANUAL OPTIONAL 


Met het bovenstaande ligt vast welke verbindingsopdrachten 
(CONNECT, DISCONNECT, RECONNECT) en in welke volgorde zijn 
toegestaan op een member-recordoccurrence afhankelijk van de geko- 
zen membership-combinatie. 

Wij zullen dit toelichten met een soort 'svntax-diagram' voor de 
combinaties 1 en 4. 


Ad 1 


i RECONNECT ħ 
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Ad 4 


STORE 


C CONNECT ) 


5 RECONNECT Ce 


In feite kan worden volstaan met de eerste membership-combinatie, 
mits uitsluitend gewerkt wordt met genormaliseerde databases. Dat 
is ook de reden waarom in het schema van $ 9.2 alleen deze eerste 
combinatie voorkomt. 


OPGAVEN 


11.1 Voer de volgende opdrachten uit op de database van voor- 

beeld 10.5. 

a. Voeg in het A-record met Al = 17 en A2 = 7. 

b. Voeg in het C-record met C1 = 1, C2 = 5 en C3 = 49, 

c. Verander B2 van het B-record met B1 = 9 in de huidige 
waarde +5. 

d. Verminder C3 met 5 van elk C-record, waarvoor geldt 
C3 > 20. 

e. Verwijder het C-record met C1 = 2 en C2 = 5. 


De opgaven 11.2 tot en met 11.6 hebben betrekking op het schema 
van $ 9.2 (vgl. opgaven 8.34-8.38). 


11.2 Voeg de patiëntbehandelingsrecords in, die zijn weergegeven 
in de tabel van opgave 8.34. 

11.3 Als opgave 8.35. 

11.4 Als opgave 8.36. 


11.5 Verwijder het patiëntbehandelingsrecord betreffende behan- 
deling DL11 op patiënt 15 op 16 juni 1982. 
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11.6 Verwijder het specialistrecord van specialist 8 en alle patiënt- 
behandelings- en medicijnverstrekkingrecords, waarin deze 
specialist voorkomt. 


11.7 Geef de 'svntax-diagrammen' voor de membership-combinaties 
2 en 3. 
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